rlucas.net: The Next Generation

(This is extremely specialized subject material. If you found it while searching, you probably understand this, but if you’re just a curious reader, you might want to skip it.)

The Continued Health Care Benefit Program is analogous to COBRA for former TRICARE-covered persons; it is mostly a transitional way to get TRICARE-like (TRICARE less military facilities) benefits self-paid after one ceases to be eligible for TRICARE itself.

Generally the CHCBP eligibility period is limited. However, in the case of former spouses of servicemembers who have not remarried before age 55, it is possible to qualify for unlimited (lifetime) eligibility. This is obvious from law and from published stuff (e.g. continuing legal education materials for the tiny subset of lawyers for whose clients this is a very important topic), but it is nearly impossible to get anything from the “horse’s mouth,” that is, the actual CHCBP plan administrator, which is Humana Military Healthcare Services (Humana Military).

If you call Humana Military at 1-800-444-5445 and ask for the rules regarding former spouse unlimited eligibility, they will punt and tell you it’s something that is decided only at the point at which the normal 3-year eligibility has expired. If you persist and ask how it’s decided, they’ll tell you that there is a questionnaire which is sent, but that they don’t have access to it and can’t send a copy. If, incredulous, you insist that some person, perhaps that person’s manager, does in fact know where the questionnaire is, since it’s obviously already written and gets sent out to people all the time, you will get transferred to a kindly manager who takes your FAX number and swears up and down that they’ll send it to you tomorrow morning since the office is about to close.

If you’re a real ornery gadfly, though, and you’re ready to start writing letters to your congressman etc., you might try sending a letter to Humana Military asking for this information and documenting your attempts to get it and the promises which were made and unfulfilled about sending it to you before. If you do all this, they will mail you a redacted copy of an actual form CHCBP-13, which had been sent to an actual former spouse whose eligibility was expiring. (Maybe, in fact, the first representative was truthful and this is not a document that they have ready, and they write up a new one every time and so the only way to send it out is to take the latest one and redact the policyholder’s personal info. I doubt it.) (For this courtesy I am grateful, O unnamed mail-replier at Humana Military, but the policy of keeping this information completely off the public Web is either backwards or sinister.)

Note that the operative requirements are:

1. A “signed statement of assurance that you have not remarried before the age of 55.”
2. Proof (the standard of which is left to the imagination) that you were “enrolled in, or covered by, an approved health benefits plan under Chapter 55, Title 10, United States Code as the dependent of a retiree at any time during the 18-month period before the date of the divorce, dissolution, or annulment (Both TRICARE and CHCPB would qualify as such a plan).” [sic — Humana’s language implies that the enrolee must have been a dependent of a “retiree” but the actual language of 10 USC 55 sec. 1078a (b) (3) talks about a “member or former member” of the armed forces]
3. “A copy of the final divorce decree or other authoritative evidence” that you are actually receiving or have a court order to receive part of the retired or retainer pay of the service member, or have a written agreement that the service member will elect to provide you an annuity. [DO NOT rely on this nor on Humana’s exact language, for this, get your ducks in a row with the statute etc. — it’s slightly complicated.]
4. The executed (signed) renewal notice page of CHCBP-013 and a check for the next premium payable to “United States Treasury.”

Given that this is a hugely important item to a few (but maybe not all that few) people out there, and that it related to the execution of very clear federal law, I’m rather shocked that there’s no mention ***anywhere on the Internet prior to today(!!!)*** of CHCBP-013 and its contents and requirements.

So, with no further ado, I present you a redacted copy of form letter CHCBP-13, which shows the actual procedural requirements for obtaining unlimited former spouse CHCBP coverage.

There are reasons why you might need to add a reference to “System.Core” to your Microsoft Visual Studio project. (For example, if you wish to compile/build both inside the IDE and from the command-line with MSBuild.exe.)

However, if you try to do this through the IDE, it will barf at you: “A reference to ‘System.Core’ could not be added. This component is already automatically referenced by the build system.”

Alas, that’s a big fucking lie. It’s referenced by the IDE when it invokes the build system, but not by MSBuild itself. So sometimes, you indeed must add such a reference, but you can’t do it from IDE-land. So close VS2010 and fire up vim. Add a line to the .csproj file in question, telling it to:

<Reference Include="System.Core" />

Hat tip to Ashby at StackOverflow:
http://stackoverflow.com/questions/1302488/the-type-or-namespace-name-linq-does-not-exist-in-the-namespace-system-data/4331322#4331322

I got to this point when recompiling something for .NET 3.5 that had originally been coded/built for .NET 4.0; it wouldn’t import the LINQ namespace without being told to import System.Linq, but then couldn’t find it without the System.Core reference being made explicit. Arrgh.

If you try to use idiomatic .NET, and you have even modest configurability architecture requirements, you will almost certainly want to use the *.config system (App.config or Web.config). According to old hands at Win32 programming, this is quite a step forward from *.ini files or registry manipulation. Perhaps so.

However, the *.config regime is extraordinarily fragile and surprise-prone once you start trying to do more than just add name/value pairs to the <appSettings> section. The following are some gotchas that I hope you can avoid if you have to deal with this.

.EXE assembies get App.config, and Web DLLs get Web.config, but non-Web DLLs (e.g. tests) get App.config.

.EXE assemblies look for filename.exe.config, which is in App.config format.  Normally, DLLs do NOT get a config file; rather, they inherit / acquire whatever config is in place in their runtime environment.  But there are two important exceptions.  Web services / sites get built as DLLs.  Their execution environment (presumably IIS or the dev server) looks for Web.config and its format.  Test projects (of the MS type that Visual Studio 2010 makes by default) get built as DLLs, as well, but they get run by (mstest? vstudio?) an execution environment that looks for an App.config file.

So, to sum:

• .EXE => App.config
• .DLL Web project => Web.config, via its server runtime
• .DLL Test project => App.config, via the test / IDE runtime
• .DLL other => none, inherits runtime environment

Sections such as <appSettings> can be externalized into other files, but there are two subtlely different and incompatible ways to do so.

Specifically, you can add a “file” or “configSource” attribute to your appSettings section.  If you use “file,” that file will be read and will override default values that are set in that section in the .config main file.  If you use “configSource,” however, you must not set any values in your .config main file, and instead must entirely scope out that section (and that section alone, save for the XML declaration) in the file whose name you specify.

Frustratingly, “file” and “configSource” have different rules for what may be included (relative / absolute paths, parent directories, etc.).  Especially restrictive are the rules for Web.config, I believe, though I don’t have them straight.  Effectively what this means is that if you have several Web projects that require a shared configuration section, you cannot put your customSection.config in a parent directory and have your projects pull it in (thereby keeping a Single Point of Truth); rather, you have to propagate multiple copies out to all of the sub-Projects (ick).

For more on this: re: configSource, re: file from MSDN.

Web.config settings are mostly inherited from machine.config down through a hierarchy, but confusingly stop being inherited at the sub-directory level in IIS.

Sometimes, or at least most of the time by default, Web.config settings for a given directory are merged with those of parent directories, and are merged with machine-level config as well.  This can lead to somewhat unfortunate results if you have an app in a subdirectory of another app with divergent configruation requirements.  This fellow seems to have figured out how to resolve this.

Be alert, though, because not all settings *do* propagate properly.  First, a parent Web.config can indicate that its settings should not be inherited.  Second, collection settings are merged together, not replaced, by child specifications.  Third, some settings, just seem stubbornly not to propagate (see this MSDN article which suggests that “anonymousIdentification” does not propagate because it is a secret never-properly-set default magical element).  Finally, the above-quoted MSDN article raises the good point that Web.config only applies to ASP.NET stuff, and that there is an entirely different regime for static content and plain old ASP files.  So watch yourself, there, Tex.

If you’re trying to use a newer (e.g. 1.3.6) version of the ruby “gem” system to install ruby packages (like rails, rake, etc.) on a legacy system with an older (v. 1.9.0) ruby installed, you might find yourself running into problems like this:

$ gem install rake

ERROR: While executing gem ... (ArgumentError)
illegal access mode rb:ascii-8bit

If you run with debugging flags, you might get a slightly more informative stack trace:

$ gem --debug install rake
Exception `NameError' at /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:163 - uninitialized constant
Gem::Commands::InstallCommand
Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem test-unit (>= 0)

Exception `ArgumentError' at /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50 - illegal access mode rb:ascii-8bit
ERROR: While executing gem ... (ArgumentError)
illegal access mode rb:ascii-8bit
/usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `initialize'
/usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `Gem::Format#from_file_by_path'
/usr/local/lib/site_ruby/1.9/rubygems/installer.rb:118:in `initialize'
/usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:257:in `Gem::DependencyInstaller#install'
/usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:240:in `Gem::DependencyInstaller#install'
/usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:119:in `execute'
/usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:116:in `execute'
/usr/local/lib/site_ruby/1.9/rubygems/command.rb:258:in `Gem::Command#invoke'
/usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:134:in `process_args'
/usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:104:in `Gem::CommandManager#run'
/usr/local/lib/site_ruby/1.9/rubygems/gem_runner.rb:58:in `Gem::GemRunner#run'
/usr/bin/gem:21

Ignore the first couple exceptions and focus on the ArgumentError right before the stack trace. What you’re seeing there is a use of a syntax for defining the binary read encoding mode for reading in a file, but it’s a syntax that didn’t make it into ruby core until ~ version 1.9.1.

However, the relevant part of rubygems/format.rb that checks for RUBY_VERSION to determine what syntax to use simply checks for RUBY_VERSION > ‘1.9’.

If you patch that to check for RUBY_VERSION > ‘1.9.0’ you’ll make some progress, but you’ll get stuck again with a similar error:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

Although this one looks quite different, it’s the same effect at play: rubygems/source_index.rb checks for RUBY_VERSION < '1.9', when it really ought to check for RUBY_VERSION < '1.9.1' when it uses a 1.9.1+ specific API (specifying the encoding in IO#read). I've added bugs at RubyForge: [#28154] Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode and [#28155] source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues Hot-patching may be required if you find yourself needing to get gem 1.3.6 working under Ruby 1.9.0. (For example, this is the Ruby 1.9 that comes packaged with Debian 4.0.) If so, it should be safe to make the changes I've indicated above. I'm hesitating to provide a patch file as I am not certain that I've got this 100% right; YMMV. Thank goodness for open source. That said, WTF is a core API item like IO#read doing changing between point versions, without it being loudly obvious in the docs??