TM1 Forum

Totally agree Forum_Fawn,

I only just got my cog-310.. surprised to find out it's already replaced.

Forum_Fawn wrote:Hey all,

Just wanted to share a little insight on the Jim Miller "TM1 Developer Certification Guide" and the "TM1: The Official Guide." Although just released in late April, Mr. Miller's book is already out of date. (I sure would hate to be his Agent right now...) The book claims to "fast track your way to COG-310 Certification," which was replaced by the COG-702 not even a month after it was released. Given previous posts that mocked COG-310's complexity, the $64.99 suggested retail is a joke. On the other hand, "The Official Guide" is a phenomenal resource. If only we could convince IBM to replace the 497 separate pdf guides with an online version of this book, the TM1 developer world would be a happier (and better?) place.

Hey, where do you see the information that COG-310 replaced by COG-702? I found in IBM website COG310 is still open for test.... http://www-03.ibm.com/certify/tests/ovrCOG-310.shtml

Test COG-310: IBM Cognos TM1 Developer

http://www-03.ibm.com/certify/tests/ovrCOG-310.shtml

Test COG-702: IBM Cognos TM1 10.1 Developer

http://www-03.ibm.com/certify/tests/ovrCOG-702.shtml

Strictly speaking it is not a replacement, just an update of the certification to reflect a newer version of the product.

They have launched a Kindle edition of the official guide.

IBM Cognos TM1 The Official Guide - Kindle Edition

I am very impressed by the influence, Alan Kirk seems to have

jpm_de wrote:They have launched a Kindle edition of the official guide.

IBM Cognos TM1 The Official Guide - Kindle Edition

Huh, I thought I'd mentioned that in a later post in this thread, but I didn't; I mentioned it in this one.

jpm_de wrote:I am very impressed by the influence, Alan Kirk seems to have

I suspect that the only influence I have in Armonk is the pressure that the back of my photograph exerts against the front of their dartboard.

I would agree that "IBM Cognos:The Official Guide" is far and away the most useful book about TM1 out there (not that there's many).

There are errors in it though. I noticed 3 critical ones when trying to replicate just one of the example models. It's in Chapter 18, pp 537-539, a very useful BOM cube. I share the errors here in the hope that someone else will avoid the hour of effort it took me to unravel them:

1. First line of p 537 - "SL Types" should read "SL Demand".
2. Towards bottom of p 538, the line
"BOM(A1,A4) * Demand A2 = 2 * 100 = 200" shoud read:
"BOM(A1,A4) * Demand A1 = 2 * 100 = 200"
3. Towards top of p 539, the second line of the rule:
"['Secondary Demand' , 'No Article']=N: should read:
"['Secondary Demand' , 'SL Articles Child':'NoArticle']=N:
(note 2 errors on that line; the dimension prefix "SL Articles Child", though illogical, is in fact needed, at least in 9.5.2, and secondly the "No Article" element should be "NoArticle", without the space).

If you build the example exactly as stated, it won't work. In one sense that was a good thing as it forced me to think about it carefully, but I'm sure that's not what the authors intended.

Perhaps there are errors elsewhere too; I haven't built any other examples yet. Or maybe this is just a quirk. Has anyone else tried to work through the examples?

In that same section there's another error - sorry i missed that in my earlier post:
halfway down p 539, the line:
" 'No Article', !SL_Demand, !SL_Periods, !SL_Types); " shoud read:
" 'NoArticle', !SL_Demand, !SL_Periods, !SL_Types); (no space between 'No' and 'Article').

Ian

I'd be very surprised to find that it makes a difference. All string comparisons in TM1 are done ignoring both case and any blanks. This applies to the identification of objects (cubes, dimensions, views etc.), to elements of dimensions and to the @= comparison and its friends. The exception to this is SCAN.

Did this actually cause an error for you or did you just notice it in passing?

Duncan,

I didn't know that about strings and object identification. That's a great bit of knowledge, so thanks!

Nevertheless it is an error in context of the text since there are two distinct elements being referred to, albeit conceptually. The other errors are indeed show-stoppers that will prevent one from completing the example.

Interestingly also, TM1 picked up the fact that "NoArticle" and "No Article" are ambiguous when used in the rule area statement, insisting that they be qualified by the dimension name. It didn't make this assertion when either element was in the right-hand-side of the rule, within a DB() function.

iansdigby wrote:Interestingly also, TM1 picked up the fact that "NoArticle" and "No Article" are ambiguous when used in the rule area statement, insisting that they be qualified by the dimension name. It didn't make this assertion when either element was in the right-hand-side of the rule, within a DB() function.

That's because "No Article" must exist as a dimension element in more than one dimension in the cube, therefore within square brackets the dimension name must be qualified to avoid an ambiguous referents (my 2c it is a good idea to ALWAYS qualify element names regardless, you never know when a new element creating ambiguity might be created int eh future). Within a DB() there is no need for this since in a DB() each and every dimension must be specified and this must be done in cube dimension order, therefore it is already known which dimension the element belongs to.

Hi lotsaram, yes, I see that's true: thank for the elucidation. Dimension order on the RHS trumps ambiguous names.

However, on the first point I think Duncan P is correct. In fact there was only one instance of "No Article" (with space). In another dimension there was the element "NoArticle", sans space. Duncan's explanation fits this scenario.

iansdigby wrote:Hi lotsaram, yes, I see that's true: thank for the elucidation. Dimension order on the RHS trumps ambiguous names.

However, on the first point I think Duncan P is correct. In fact there was only one instance of "No Article" (with space). In another dimension there was the element "NoArticle", sans space. Duncan's explanation fits this scenario.

I agree. I just didn't think it was worth mentioning that "No Article" existing as an element could just as well be "NoArticle", "NO ARTICLE", " nO A R T icl E", or any of a bazzilion other possible combinations as when it comes to object and element names TM1 doesn't know or care about spaces or case.

I like the IBM documentation in the book.