Planning Analytics 2.0.9.9

[Wim Gielis]

Planning Analytics 2.0.9.9 is out (July 14, 2021)

An admin can move/delete the post, I just wanted to signal this

[scrumthing]

Currently it somewhat becomes hard to keep track of the new versions.

[Alan Kirk]

Currently it somewhat becomes hard to keep track of the new versions.

Maybe not that hard given what is pinned to the very top of this forum.

I was aware of the release, but I don't always have time to write it up on the very day of release. Besides, anyone enthusiastic enough to throw themselves into the abyss of a bleeding edge release on day 1 is free to do so, but I don't feel comfortable holding their hand.

[Wim Gielis]

Currently it somewhat becomes hard to keep track of the new versions.

Maybe not that hard given what is pinned to the very top of this forum.

I was aware of the release, but I don't always have time to write it up on the very day of release. Besides, anyone enthusiastic enough to throw themselves into the abyss of a bleeding edge release on day 1 is free to do so, but I don't feel comfortable holding their hand.

It’s on my own laptop only. I was still on 2.0.8 from 2 years back so that was about time to move on.

[Alan Kirk]

Currently it somewhat becomes hard to keep track of the new versions.

Maybe not that hard given what is pinned to the very top of this forum.

I was aware of the release, but I don't always have time to write it up on the very day of release. Besides, anyone enthusiastic enough to throw themselves into the abyss of a bleeding edge release on day 1 is free to do so, but I don't feel comfortable holding their hand.

It’s on my own laptop only. I was still on 2.0.8 from 2 years back so that was about time to move on.

My conundrum is this; as per my profile at the time of writing I'm still on 2.0.6 which goes out of support in a couple of months. We're in the midst of a finance systems transformation project at the moment and will want to go live when the time comes with a supported version of TM1. Sooooo... do I commit to 2.0.9.9 (given that contrary to IBM's view, upgrading production software in most companies of more than 5 people does NOT involve "Oh yeah, let's just run an update"), or do I play it "safe" and stick to say 2.0.9.7? I probably WOULD have gone for the latter, save for the number of "blow up the server" bug fixes in 2.0.9.9. Thankfully I don't have to make the call quite yet and will have time to see whether there is a repeat performance of what happened with 2.0.9.8.

[Wim Gielis]

Right. So you upgrade to 2.0.9.9 (over an existing 2.0.8 install) installing the server, Architect and Perspectives, TM1 Web and a bunch of other things that are not important for now. 2 small TM1 models are opening fine in Architect when their respective services are started and the data is loaded.

You start TM1 Perspectives from the Windows Start menu. Excel opens fine with some other addins (of mine, and Jedox, a.o.). No workbook is active/opened. You use TM1 > Explorer to log on in Perspectives. You open a view on a random cube and ask for an Active form to Excel. Nothing out of the ordinary I would say.

Bam ! Error !

14.png (59.36 KiB) Viewed 47231 times

Bam ! Another error !

15.png (92.26 KiB) Viewed 47231 times

To IBM: is it so freaking difficult to ask whether "ActiveWorkbook Is Nothing" ? Yes or No ? True or False ? Because if indeed 1 or more workbooks do exist prior to asking for an active form, it works fine. But the active form is created in a separate workbook, therefore an active workbook is actually not needed at the time of the active form. Anyways, seems to be never solved this one. 1 line of code

[Alan Kirk]

To IBM: is it so freaking difficult to ask whether "ActiveWorkbook Is Nothing" ? Yes or No ? True or False ?

"But it doesn't comply with our strat-teh-gee. Our strat-teh-gee is not to provide any functionality or fix any bugs that users who have already forked over their money (regularly and in large volumes) want and/or need unless it coincides with something that we can use in a sales presentation to lure in more potential suck...er, customers.

You cannot question the strat-teh-gee. If you do we will stick our fingers in our ears and sing 15 choruses of "Kubernetes, Great And Good". Therefore the strat-teh-gee is perfect and cannot be questioned."

Because if indeed 1 or more workbooks do exist prior to asking for an active form, it works fine. But the active form is created in a separate workbook, therefore an active workbook is actually not needed at the time of the active form. Anyways, seems to be never solved this one. 1 line of code

Yup. They've been pretty blunt that they won't be doing jack to Perspectives in the future, not even one lousy line of code.

[burnstripe]

You start TM1 Perspectives from the Windows Start menu. Excel opens fine with some other addins (of mine, and Jedox, a.o.). No workbook is active/opened. You use TM1 > Explorer to log on in Perspectives. You open a view on a random cube and ask for an Active form to Excel. Nothing out of the ordinary I would say.

This isn't due to a mix match of bit versions is it? My guess would be you have a 32 bit version of excel and it's opening a 64 bit version of the application. If excel is 32 bit make sure the tm1p.xla the perspectives shortcut points to is in the bin folder, not the bin64 folder. Also may need to run this to finish the job..
https://www.ibm.com/support/pages/tm1xl ... rspectives

Alternatively are all the addins / comaddins showing/activated

[Alan Kirk]

You start TM1 Perspectives from the Windows Start menu. Excel opens fine with some other addins (of mine, and Jedox, a.o.). No workbook is active/opened. You use TM1 > Explorer to log on in Perspectives. You open a view on a random cube and ask for an Active form to Excel. Nothing out of the ordinary I would say.

This isn't due to a mix match of bit versions is it? My guess would be you have a 32 bit version of excel and it's opening a 64 bit version of the application. If excel is 32 bit make sure the tm1p.xla the perspectives shortcut points to is in the bin folder, not the bin64 folder.

You may want to take a closer read of the previous two posts; Wim already spells out why the errors occur and what would be needed to fix them. Or would be if IBM could be bothered, which they have made clear they won't be.

Also if you try to use a 64 bit add in on 32 bit Excel you won't even get that far; just trying to load it will land you in a sea of errors.

The add-in will try to run the Calculate method of the Excel Application object before it generates an active form. Except that method will fail with an error if there is nothing to calculate. That is, if no workbook is open. The problem is that the add-in doesn't check for that possibility. That's the error in his first screenshot.

The add-in later tries to do something with the existing active workbook... of which there wasn't one, therefore the object reference is null, therefore BOOM, you get the second error.

Again, this is something that the add-in should check, but doesn't.

As Wim said, one line of code would fix it. And that line will never be written, because IBM's strat-teh-gee is to make no further updates to Perspectives.

[Wim Gielis]

A defect was logged with IBM for this one, as well as for another more important problem in Architect 2.0.9.9.

I have an existing TI process that opens fine in PAL 2.0.8.

There is code like this:

Code: Select all

ExecuteProcess( 'TECH_restrict cube selections' );
  , 'pCube', 'CUBE NAME'
  , 'pView', 'VIEW NAME' );

I know that this is against the rules. But if you are then observing 2 things:
- either TM1 Architect crashes completely (not the server)
- either the process opens without any error message but the said Prolog tab is completely empty (!)

Pretty harsh I think, as a reaction to my typo. Turbo Integrator in 2.0.8 was more benevolent and compassionate.

[burnstripe]

Sorry I hadn't full read. I agree it's a bug. There is a workaround of adding the addin to excel, and then launch perspectives via excel rather than from the perspectives shortcut. That way there will be a excel book/sheet already open. But it'll probably not get sorted

[Alan Kirk]

A defect was logged with IBM for this one, as well as for another more important problem in Architect 2.0.9.9.

I have an existing TI process that opens fine in PAL 2.0.8.

There is code like this:

Code: Select all

ExecuteProcess( 'TECH_restrict cube selections' );
  , 'pCube', 'CUBE NAME'
  , 'pView', 'VIEW NAME' );

I know that this is against the rules. But if you are then observing 2 things:
- either TM1 Architect crashes completely (not the server)
- either the process opens without any error message but the said Prolog tab is completely empty (!)

Pretty harsh I think, as a reaction to my typo. Turbo Integrator in 2.0.8 was more benevolent and compassionate.

Assuming that IBM is true to their word and aren't touching Perspectives / Architect, I can understand how a change in the server can cause the second of those. Given the number of bug fixes that have involved TI code over the whole of the PA2 family of releases, the server may now simply be rejecting faulty code as a safeguard which is why it ends up vanishing. But yes, I agree that it's rather harsh. Baby with the bathwater and all that.

I was originally going to say that I couldn't quite see why a server side change should be triggering an Architect crash... BUT then I remembered how things were with the classic API, which I've barely touched for a couple of years now. You had to validate the living hell out of the value capsules, and one wrong move could easily and readily crash the host application. Architect is of course powered by the classic API, so it really doesn't surprise me as much as I originally thought.

Of course, I use the legendary Arc for TI editing almost exclusively these days so I don't have this problem. (Out of curiosity I'll try that code when I have 2.0.9.9 in a sandbox, but my expectation is that Arc will just say "I can't compile that, please fix line 3" (or words to that effect).) A key difference of course being that Arc uses the RESTful API which Architect never will.

[Wim Gielis]

Should it not be changed by IBM, then I can see a number of consequences:
- editing a PRO file directly in a text editor and rebooting TM1 becomes a very risky undertaking
- when upgrading to those newer versions and using Architect, one should be absolutely sure that all processes are correct with respect to syntax.

Two very important messages if you ask me.

[Alan Kirk]

Should it not be changed by IBM, then I can see a number of consequences:
- editing a PRO file directly in a text editor and rebooting TM1 becomes a very risky undertaking

Although I sometimes live life on the edge in the way a lot of old school admins do, I have to admit that I don't think I've ever done that. Not in production, anyway. In the pre-Arc days I used to edit in Notepad++, but I'd always copy the code to a dev server and made sure that it compiled before copying and pasting to production. Of course the down side of that is that this only allows you to edit code, not variables, parameters or default data sources the way you could if you directly edit the text file as mentioned above.

Way back in the day I was trying (not very seriously, I admit) to create my own TI editor with the (classic) API. But while that API allowed me to do a lot of amazingly cool things (albeit usually with clenched teeth and beads of sweat dripping from my brow waiting for the next crash), the API commands relating to updating TI processes seemed to be a little bit too finicky and esoteric (and possibly not fully documented; what a surprise that would be) for me to be able to do it reliably. I ended up giving up.

In both cases (hacking the text files and using the classic API) there were too many moving parts for me to feel comfortable with so I chose not to go down those paths and live with a combination of Notepad++ and the Editorsaurus.

- when upgrading to those newer versions and using Architect, one should be absolutely sure that all processes are correct with respect to syntax.

Two very important messages if you ask me.

Or the third one, more people will buy Arc and see their blood pressure drop by 30 basis points. (Yes, I know that I keep banging on about Arc but it is just SO. GOOD.)

But yes, I agree, to me anything that gratuitously destroys peoples' work, regardless of how good the intentions, needs to be addressed.

Now for a slight tangential deviation from subject, but it's amusing anyway. I was looking up some information about PowerShell profiles (specifically altering the console display) and I came across this:

There are no words to describe how much I hate what Microsoft did here. I am working on a VM, it is past midnight and the standard color scheme is very difficult to read. For some ridiculous trendy reason, the background on PowerShell is black.

(NB: This is about PowerShell Core, not classic PowerShell .Net which is of course blue.)

I went in and changed the text to black and the background to white. i did this in Default and Properties. Well, because of the syntax highlighting, my color changes did not do what I think any reasonable person would expect. The background did become white, but the text was yellow and it was even harder to read.

I found you very informative article and surprise, surprise, Microsoft provides a great deal of customizability, but not through their GUI. It is very hard to type the commands when I can't read what I am typing.

A bit like a company that expects you to go faffing around in command lines and manually editing text files in 2021, but let's not name names. The funny part was this reply, though it wasn't intended to be:

In the upcoming new world, it will be less relevant whether people hate a vendor for such things, because they typically don't care --

{Sucks air through teeth...} Yeah, that sounds oddly familiar...

instead, they will be financially liable for the wasted time users encounter when standard instructions no longer work.

BWAAAAH-HA-HA-HA!!!! You're talking cr@p kid; that world will never exist. But {insert dream sequence optical effect here} imagine if it did. I'd never have to work a day again in my life, all on IBM's dime... You'll all be invited (not all at once, of course) to my 40 bedroom palazzo in the countryside of Lazio, with my 40 acres of olive trees, 4 Olympic sized swimming pools and {calculates the amount that IBM owes me...} personal health spa with 20 massage therapists and 10 spa baths.

[ykud]

Should it not be changed by IBM, then I can see a number of consequences:
- editing a PRO file directly in a text editor and rebooting TM1 becomes a very risky undertaking

Although I sometimes live life on the edge in the way a lot of old school admins do, I have to admit that I don't think I've ever done that. Not in production, anyway. In the pre-Arc days I used to edit in Notepad++, but I'd always copy the code to a dev server and made sure that it compiled before copying and pasting to production. Of course the down side of that is that this only allows you to edit code, not variables, parameters or default data sources the way you could if you directly edit the text file as mentioned above.

I always get tripped up by the fact that the last line of the section records the number of lines in it, i.e.

Code: Select all

575,84

means that there are 84 lines in Data.

So when I add a line in Notepad++, I need to update that counter, otherwise TM1 just silently ignores it

[Wim Gielis]

I always get tripped up by the fact that the last line of the section records the number of lines in it, i.e.

Code: Select all

575,84

means that there are 84 lines in Data.

So when I add a line in Notepad++, I need to update that counter, otherwise TM1 just silently ignores it

I edit PRO files everyday. Heck, I even wrote an AutoHotKey script to update the counters for me

But if a typo will lead to completely empty code tabs in TI, the stakes are very high.
Even more, what if TI opens the tab as blank but would also do a Save of the file… or the user does it in TI inadvertently… a lot of code can vanish in the PRO file at the blink of an eye.

[Andy Key]

I always get tripped up by the fact that the last line of the section records the number of lines in it, i.e.

Code: Select all

575,84

means that there are 84 lines in Data.

First line not last line. 575 is the start of the Epilog...

[ykud]

I always get tripped up by the fact that the last line of the section records the number of lines in it, i.e.

Code: Select all

575,84

means that there are 84 lines in Data.

First line not last line. 575 is the start of the Epilog...

Shows then I last edited it directly Thanks heaps for correction -)

[scrumthing]

Or the third one, more people will buy Arc and see their blood pressure drop by 30 basis points. (Yes, I know that I keep banging on about Arc but it is just SO. GOOD.)

AGREED!

[Wim Gielis]

Should it not be changed by IBM, then I can see a number of consequences:
- editing a PRO file directly in a text editor and rebooting TM1 becomes a very risky undertaking
- when upgrading to those newer versions and using Architect, one should be absolutely sure that all processes are correct with respect to syntax.

Two very important messages if you ask me.

After a careful inspection by an IBM engineer, S. Seigneurie, it appears that there were 25 variables in the file.
Yet the line indicating the count of the variables, said 28.
I honestly don't know if I did that myself, or that this was the result of using any of the TM1 clients and ending up with that wrong count.
When the count is corrected, the crashes and losses are not there anymore.

Editing PRO files manually has become riskier, it seems. There have been 2 defects solved in the meantime that could have had a side effect on TI being less "friendly".