This morning I moved the database backing the Muonics web site to a new server–part of our on-going (but thankfully almost complete!) IT infrastructure upgrades that have been consuming so much of my time of late. I haven’t seen any problems with the site yet, but if you notice any that aren’t resolved quickly, please do let me know (either by comment or email to support).

The web site itself will also be moving to a new server soon, once we’ve got email services integrated with our LDAP server (another of many upgrades to our internal systems I hope to write about in the articles section soon). Then we can retire the old server hardware that’s been in operation since 2001 when our flagship product, MIB Smithy, was just a spark of an idea.

I’m totally amped to get the last of this migration done. For one thing, I’ve been feeling a bit down on myself for getting behind on product development and neglecting to get the articles section rolling (too many commitments over the last year or two), and it will free up time to get back into it. But mainly I’m amped because of all the potential for reducing drag.

Internally, I’m looking forward a ton of automation, ability to handle and delegate to more staff, room for expansion, speed and capabilities that moving all our x86 platforms to high-end hardware running VMware Server will provide.

Externally, you can soon expect IPv6 and 64-bit platform support for our products and speeding our release cycle back up. We’re bringing the popular FogBugz bug/support tracker online with the last bit of web/email server migration, and I hope to have it integrated directly into our products soon thereafter. Since we’ve outgrown our current bug/feature tracking systems, and email inquiries aren’t currently handled directly through a tracker, this should be a big improvement in our planning, scheduling, and handling of such inquiries.

Overall I’m excited because all of these changes, while they’ve been time consuming and occasionally frustrating, represent a whole new chapter for Muonics: one that will feel to me much less like a startup and much more like a well-oiled machine.

MIB Smithy 4.0.8 provides bug fixes for the following issues:

• The right-click popup menu in the Project Tree will no longer show for Type/Value Assignment virtual folders as it was actually showing the menu for the module. Consequently, selecting “Remove” would remove the module, rather than all Type/Value Assignments as one might expect.
• A “record search string is ambiguous” error would occur when sorting OIDs for generating some output formats if the name assigned to one of those OIDs was also used in another module.
• An “invalid command name” error could occur when trying to show the calendar popup for REVISION and LAST-UPDATED timestamps due to a trace not being removed after the popup is hidden.
• Removed conversion of spaces to HTML entities in help file:// URLs under Windows to prevent errors launching help when MSIE 7 is the default browser.

An unknown variable error that would occur when adding a MIB if either a file with the same name was already added or if copying/linking the file into the mibs directory failed, rather than the intended dialog, and was corrected in this release.

Changes in this release:

• nmtrapd under Linux could max out CPU usage due to Linux-specific handling of select() timeouts.
• Newlines and carriage returns in OCTET STRING values were forcing conversion to hex (such as in varbind values in responses) as if they were non-printable characters.
• A crash could occur if the environment variable for pointing to the license key file were mistakenly set to a directory instead.

Changes affecting MIB Smithy:

• A “wrong # args” error could occur when previewing a single OBJECT-TYPE in SMI format (the error did not occur when previewing the whole module).

Changes affecting both MIB Smithy and MIB Smithy SDK:

• The “piberrors” type in the XML-SMI Schema document was not correct and did not match the implementation and has been corrected.
• Newlines and carriage returns in OCTET STRING values were forcing conversion to hex (such as in varbind values in responses) as if they were on-printable characters.
• A crash could occur if the environment variable for pointing to the license key file were mistakenly set to a directory instead.