Figuring out why a Cognos report that ran just fine before now seems to want to run the entire report query before I even get to the second cascaded prompt… not easy, but I’m guessing “bug”. Must I upgrade again?

I’ll start this out by mentioning that I know about PLMXML, and it’s not what I want.

Here’s what I want: a standard format that vendors can use to exchange information about the lifecycles for their products.  Ideally, there would be standardized lifecycle phases that would mean the same thing across all implementations, and standard lifecycle formats.

Haven’t seen that anywhere here on the Intertubes, and I’m thinking of working on proposing and/or developing a standard for it with others who seem to like the idea, but I wanted to throw the idea out there so that I don’t spend the next three months on a specification only to be told “Oh yeah, we already did that two years ago, and we’re all smarter than you are, so we addressed all these other issues that you didn’t think about.”  And then they’d give me a wedgie.

Simple stuff really: I want to be able to import this info into our architecture repository so we can start comparing the technologies used by our apps to the vendor lifecycles, and feed that as a big chunk of data into our strategic planning.  You have an app that will still be up and running in five years, but all the technologies it’s running on will be end-of-support-life in one year?  Well, then your five-year-plan had better include a project to upgrade it, hadn’t it?

Basic attribute requirements for a high-level component in the XML would be:

  • Technology Name
  • Technology version/subversion(s)
  • Product description
  • Technology type (hardware product model, software product version, industry standard version)
  • Lifecycles (should be several, these are just examples): Beta, Supported Release, End of Standard Support, End of Extended Support, Discontinued
  • Each lifecycle has a start date and an end date, at a minimum.  The last cycle’s end date can be “infinite” or “undetermined” or something similar
  • Each lifecycle (and the versioning doc as a whole) can have a categorization as to how public the knowledge is, ranging from “freely available” to “confidential”, but that doesn’t mean there’s DRM on the XML doc itself.  That’s a separate security and control question.
  • Comments for lifecycles and for the component
  • URIs to the most recent version of the lifecycle doc for this technology

See?  Simple stuff.  But so simple I expect someone has at least looked at it.


We have three different types of applications or software that are hosted on Citrix servers: pretty typical stuff.

  1. Fat client runs on Citrix, connects to a back-end hosted somewhere else
  2. Thin client (browser) runs on Citrix, connects to back-end hosted somewhere else
  3. Standalone client runs on Citrix directly, no back end.  Office applications (e.g., Word, Access) as well as full-blown virtual desktops fall into this category.

Option (2) always sounds like a strange one (wouldn’t any Citrix client also have a browser installed?), until you realize that we use those for remote connections.  We don’t allow direct access to internal applications from the outside world, but you can either VPN in or connect to the external network-facing Citrix boxes, and then run the apps from there.

We run Troux’s Enterprise Repository to model our Enterprise Architecture world, including the relevant parts of our application portfolio, and I’m trying to find the most appropriate way to model the Citrix relationships.  You see, in Troux’s world an application runs on software modules, which are instantiations of specific versions of software products on infrastructure components.  So as an example, an application (which is a business construct, referenced as a whole, different from the component pieces of software like MS SQL) called “HR Payroll Processing” runs on MS SQL 2005 on Server1.  In that case, the Application is “HR Payroll Processing”, the software module is “MS SQL 2005 on Server1”, which is an object that links the app to the server, and the infrastructure component is Server1.

We have never traditionally used any software modules for the clients.  In fact, we’ve never represented the clients (fat or thin) in the EA repository: never really needed to.  I’m trying to figure out whether it makes sense for us to model the clients that are installed on Citrix servers using software modules, or whether it actually makes more sense to use a different object type. Has anyone out there dealt with this?  Not necessarily on Troux, I’d be interested in hearing about experiences on any EA modeling tools.  My idea is that we would create, for the cases above:

  1. Software modules called “HR Payroll Processing Client – CitrixServer1”.  These would link to the application and the server objects.
  2. Software modules called “Browser Client – CitrixServer1”.  These would link to the application and the server objects.
  3. Software modules called “<Software name> – CitrixServer1” (e.g., “Outlook 2007 – CitrixServer110”).  These would link only to the server objects.

One of the complexities of this model is that we need to produce reports that show the owners for everything installed on the Citrix servers for DR and general operational purposes.  But now this means I have to assign owners to the Citrix installations of standalone software like Office, and the report will have to show the union of owners of the first two types (which is a secondary link to the application owner relationships) and the standalone software.

In the alternate approach, I create Application objects for each of the Citrix installations of standalone software, maybe make them children applications of a parent “Citrix implementation” app. This seems duplicative to me (an app called “Citrix Outlook 2007” that runs on a software module called “Outlook 2007 – CitrixServer1” that runs on “CitrixServer1”), in addition to going against our standard application definition which states that software <> application.  There are pros and cons to each approach, but we’re early enough in our EA gathering that we don’t know how this information will be updated and used in the future, so it’s hard to understand where the additional work will be least annoying: in the work needed to create additional application objects, or in the need to create output reports.  Either way, someone’s going to be doing more work than strictly necessary in order to make the output look consistent, and I know that if I have to create additional application objects that person will be me.  I’ll do it if I have to, but I want to make sure I’m doing the right thing.

Probably just open musing at this point: I know that if someone asked me this question my answer would be “it depends”.   Anyone else been working on EA modeling?  Anyone modeled their Citrix apps?

I’ve been burned by this one so many times it’s not funny.  Although if you like seeing me get frustrated, then I guess it is funny.

Here’s the issue: you have a SQL SELECT statement that you’re using in a Cognos Report Studio report, and you’ve verified that it is syntactically correct. It runs fine in Studio Express, for example.  But then you try to add a filter (also one that is syntactically correct) in Report Studio, and you get an error.  The SQL SELECT statement is correct, the filter is correct, but enable the filter and if fails.  What…?

Short answer: Don’t put “ORDER BY” sort statements in the SQL SELECT command. Your order statements should only occur in Report Studio.

Long answer: 

The reason this errors out is that when you put in a filter in the report (not in the original SQL SELECT), Report Studio adds that filter to the end of the SELECT statement it constructs.  So if the SQL is:  

SELECT ApplicationName from R_Applications

And you add a filter like “[ApplicationName]=’something’”, then Cognos bundles them together and sends this request to the SQL server:

SELECT ApplicationName from R_Applications 
WHERE [ApplicationName]=’something’

If the statement in the original SQL is

SELECT ApplicationName from R_Applications
ORDER BY ApplicationName

Then when Cognos sends the statement with the filter enabled it sends:

SELECT ApplicationName from R_Applications
ORDER BY ApplicationName
WHERE [ApplicationName]=’something’

Which is a syntax error: WHERE cannot come after ORDER BY.

Ta da!

Caveat: running v8 of Report Studio, I hear rumors that this behavior changes slightly in later .x revisions.

When you create burst reports or run any Report Studio report so that it sends the results out as an email, you have a few options on the format in which the file goes out. Some of them don’t work so well in our environment because of restrictions on file types that we have in our email systems, so .htm or .html files will never make it past our filters: that one is obvious. What other types can you send reports out as?

  • CSV: success!
  • XML: success!
  • PDF: success!
  • Excel: FAIL!

That last one is a little confusing, to say the least. I would expect XML to fail before XLS. There’s a reason it does fail, though: no matter how you attempt to send an Excel attached file, Cognos actually sends out an .mht file instead, albeit with a MIME type of application/ In my mind this is astonishingly backwards, especially considering there is no indication of what it’s going to do and why.

In any case, here’s how to fix it: you must add a server parameter to send the mht file using an .xls extension. This means you’re still sending an .mht file, but it at least looks like, and behaves like, an Excel file. To do this you must add a server parameter.


  1. Click the Tools menu in the Cognos portal and select “Server Administration”
  2. Select “Set Properties” for ReportService
  3. Select the “Settings” tab
  4. In “Advanced Settings” (usually the first option), click the ‘Edit…’ link
  5. Select “Override”
  6. In the first empty set of boxes, type in the parameter name RSVP.FILE.EXTENSION.XLS and set the value to TRUE

Repeat the above steps to Set Properties for BatchReportService, and when you send the reports send them as Excel 2002 (NOT as Excel 2000 or Excel single sheet).

Not very smart, misleading, and the cause of the error you get when you try to open an “Excel” file that came from Cognos, where it states that the file is not in the format that the extension indicates. An error that you get every. time. you. open. the. file.

A topic obviously near and dear to my heart.  It’s an article in CIO magazine, which by definition kind of means it will be superficial (it’s the same magazine that produced the lightweight “Apple as the enterprise desktop” I linked to some weeks ago).

To make it worse, they do the usual “post only two paragraphs per web page so you have to visit more pages and get more ads” trick which annoys me to no end, so here’s the list of things you should know:

  1. Telecommuting Saves Money. Truly.
  2. Telecommuters Really Can Be More Productive
  3. Telecommuting Doesn’t Work for Every Individual
  4. Trust Your People
  5. Hone Management Skills for Telecommuting
  6. Keep the Telecommuter in the Loop
  7. Tools and Technology Make a Big Difference

It also has an interesting sidebar that asks questions about who should pay for the tools the telecommuter users.  Doesn’t give any answers, but it does mention the things that need to be considered.

I have my opinions about #7, specifically on who should pay for a 30″ Apple monitor that would fill a very empty space on my desktop.  Plus the 8-core Mac Pro that would be attached to it, of course.

Here are a few more that the CIO needs to know about:

  • Telecommuting doesn’t work for every job.  While the article mentions that it doesn’t work for every individual, it neglects the fact that there are some jobs for which telecommuting isn’t appropriate.  If the employee needs to be physically present to power systems on or off, that’s an obvious misfit, but there are also many jobs where most of the work has to do with relating to people directly (for organization, coordination or influence), and which may be poor candidates.
  • Telecommuting has significant benefits for the organization and the employee, but has drawbacks for the employee in job and promotion opportunities.  As I’ve said many times in the past: it’s a tradeoff.  But the employer should not fall into the trap of considering telecommuting as a “reward” that somehow is nothing but the opportunity for the employer to goof off.
  • There’s more travel involved than you’d think.  When I started telecommuting, we did some calculations about how often I would have to travel back to the office locations, and I believe we said something along the lines of “once every six weeks or so”.  There’s been far more travel than that, and potential full-time telecommuters need to understand that this is vital for them to remain on the agenda and in other people’s minds.
  • Don’t underestimate the benefit of a good desk and a comfortable chair: you’ll be using them more often than you would in the office (you never have to get up to go to a conference room, since you’ll take all conferences on your phone).  A good keyboard is also vital, but OSHA regulations tend to be downplayed or ignored.

Something I learned when using Attensa, but that works very well in our current (test) implementation of NGES, and should work in any RSS/Atom feedreader that dumps blog entries into subfolders in Outlook. I've been using what I've found to be a very efficient way to read Atom/RSS feeds within the folders in Outlook, but it requires Outlook 2003: use a very simple search folder.

NGES, by default, puts each feed into a separate folder under a top-level "Feeds" folder. Normally, you'd have to open each folder individually to read it, which doesn't lend itself well to the type of "skimming" reading that many feeds require (I'm looking at you,

Here are the steps:

  • Right-click on "Search Folders" in Outlook 2003, select "New Search Folder"
  • Select Custom – Create a custom Search Folder Click "Choose" to specify search criteria
  • Call the new folder whatever you want (e.g. "All Feeds") Select, for the folders that will be included in the search folder, the NGES "Feeds" folder only, and leave "Search in Subfolders" turned on
  • Click "OK" on the warning that you have not specified any criteria
  • When the search folder populates, make sure that the view is arranged by folder (top of the view)

Voila! A single folder with all of your unread RSS/Atom feed items. You can select a "feed"/"folder" by clicking on the sorting group title (which has the feed name), and actions performed against that title are performed against all the feed entries: you can catch up on a feed and delete all items, for example, by selecting the folder and hitting "Del". You can go from item to item by using the space bar. Since the search folder is just a view, whatever you do to the entries in that folder is done to the original items.

Advanced capabilities:

  • hitting the space bar will go through the items and to the next unread entry, but depending on how you have Outlook configured, the item may or may not be marked as "read" automatically (mine is configured to not "mark as read").
  • Because this is a search folder capability, you don't need to limit yourself to just one view: the filters can be customized even further, and you can have separate, independent views of your feeds. You can aggregate from all your feeds only entries with specific keywords (I have an "enterprise architecture" and an "XML" view) into a single view, or categorize your feeds into groups by using search folders that only view specific subfolders under "Feeds".
  • You can categorize and search by date, subject, author, anything you want, and the view is populated automatically by Outlook's quite powerful search folder capabilities.
  • You can see how many unread items are in your entire set of feeds (the NGES "Feeds" folder only allows you to see how many unread items there are in each feed)
  • If you're really geeky and are using the GTD Outlook add-in, you can even create tasks and events off blog entries ("Read this later", "Comment on this blog")

Important note: remember as you're investigating possibilities here, that each entry in an NGES feed is a "Post" item, not an email item. I found this out the hard way after trying to troubleshoot a search folder that relied on an email-specific property, when the fact that the icon for the entries is a "post" icon. In my defense, I had the icons turned off at the time.