Commuters Have Political Clout

The recent elections have shown Hartford an important fact:  the 120,000 daily riders of Metro-North have political power. 

The Commuter Action Group, of which I am founder, endorsed only five candidates for election and they were all winners.  (Trust me, there were many others seeking our endorsement, but they didn’t have the track-records (pun intended) to warrant our support.)

Those we backed have long supported mass transit. They have fought for more funding and understand their commuting constituents’ frustrations.   All we did was remind voting commuters who were their real friends in Hartford versus those who were just paying lip-service to the issue during a campaign.

While I have disagreed with him in the past (and will probably do so again), Governor Malloy was an easy choice.  His opponent was just the latest dilettante billionaire to be chosen by the GOP (remember Linda McMahon’s two runs for office costing $97 million?), by-passing experience political veterans.  Tom Foley was just clueless, saying such things as “we spend too much on mass transit” and surrounding himself with “yes-men” advisors.  Even his fellow Republicans on the ballot couldn’t talk sense into him.

What would give Foley or McMahon, neither of whom have ever been elected to anything, the idea that their track records as CEO’s would qualify them for the job of Governor?   A CEO can snap his fingers and say “do this or you’re fired”, but a Governor has to deal with a legislature, and in Foley’s case, it would have been of the opposing party.  Good luck with that.

Trust me… I am not a fan of one-party rule.  With their huge majority and deep pockets I think the Democrats in this state have become abusive bullies. 

So why does the GOP keep choosing these kinds of candidates, aside from the fact that they can bankroll their own campaigns?  What a shame that veteran State Senator John McKinney didn’t get a chance to run against Malloy. McKinney was very strong on transportation issues. That would have been an interesting race.  Maybe in 2018?

Because we are non-partisan, the Commuter Action Group also endorsed three Republicans… State Senator Toni Boucher and State Rep’s Gail Lavielle and Tony Hwang, as well as Democrat Jonathan Steinberg.  They were all winners, not because of our endorsement but because we helped remind commuters they have been strong allies in Hartford.

What did we ask for our endorsement?  Only a single pledge:  that, if elected, they would promise to do something never done before… to caucus, Republicans and Democrats together, with fellow lawmakers from electoral districts representing commuters.

It was amazing for me to learn that doesn’t happen… that R’s and D’s from Fairfield County never get together to present a united front against up-state lawmakers’ attempts to cut funding for our trains.  Well, it will happen now!

Back in the dark days of February when the Commuter Action Group was formed, I reminded Hartford lawmakers that if they didn’t come to the rescue of our trains, that commuters would “remember in November” who their friends were.  And clearly they did. 

2014 ODTUG board of directors election results

First of all, thank you

You have, perhaps a trifle unwisely, reelected me to the ODTUG board of directors.  Thank you and I will do my best to serve all ODTUG members to the best of my ability.

I have to say that given the intense campaigning this time round, I was pleasantly surprised to be reelected as this blog post is all that I did to announce my candidacy.  So again, thank you for your belief in me and I will do my best to not let you down.  I may even make you happy.  :)

Who got elected

Yr. obt. svt.

You are reading my blog, perhaps you even voted for me.  You know who I am for better or worse, and as I wrote before, thank you for voting for me.  

Tim Tow

Tim has been treasurer for as long as I’ve been on the board and was originally (I think I have this bit right) appointed to the board when ODTUG first welcomed what was then called Hyperion back in 2008; he subsequently ran for the board and is now on his third reelection.  Tim is also a personal hero of mine; anyone who knows him in the EPM and ODTUG community knows and respects him as well.  Tim and I are both reaching the end of our six year term limit so this will be it for him, at least for a while.

Mike Riley

Mike is a former ODTUG president (so slightly insane then, but nice) and Kscope conference chairman (again with the slightly out of his mind, but again thankfully someone took on that Herculean task).  He hit his six year term limit last year, took the mandatory year off and is back.  

Mike helped bring EPM to what was then called Kaleidoscope, so everyone who reads this blog owes a debt of gratitude to him.

I don’t think anyone can doubt his dedication to ODTUG and drive.  I look forward to serving with him again.

Sarah Zumbrum

Sarah is new to the ODTUG scene and has seemingly exploded out of nowhere.  That’s not actually true as she was a member of the former Hyperion SIG.  I’ve worked with Sarah on the EPM Community initiative and have been very pleased with her work ethic, determination, and ability to lead the other volunteers.

She will make a great contributor to ODTUG and I look forward to serving with her for the next two years.

What I’m going to do after this term

ODTUG board members are currently limited to three contiguous two year terms.  After that, they must take at least a one year break.  This upcoming two year term will therefore be my last as 2014 is the end of year four for me.

But it’s going to be more than just the end of my maximum three concurrent terms – the upcoming 2014 to 2016 term is it, there ain’t no more to give, I’m moving out, it’s Arrivederci, Auf Wiedersehen, Tot Ziens, and Cheerio after that.  

It’s not that I don’t love ODUTG, but I feel that six years is more than enough time to enact whatever vision I have (I am speaking for myself and no other board member) and with the grassroots EPM Communities initiatives I am managing (Ah, management:  I give very few general directions, which are largely ignored and rightfully so, and Jennifer Anderson, Courtney Foster, and Sarah Zumbrum along with a bunch of other people do all the work and somehow credit is accreted to me.  Why am I not a manager in real life?) I think I have found the task that strikes passion in my ODTUG heart.

So I have two more years to help get the EPM Community initiatives get their sea legs, do all of the other sundry tasks and requirements of ODTUG board members (some are quite exciting, others deadly boring, so just like a real job), and then get out of the way for the next group of volunteers.

Am I divorcing ODTUG?  Is this a community property state?  Who gets custody?

Absolutely not.  I owe a huge professional and personal debt to ODTUG – it has had all kinds of impacts on my career.  These include:

• Writing a book – Developing Essbase Applications:  Advanced Techniques for Finance and IT Professionals
• Becoming first an Oracle ACE and then an ACE Director
• Meeting a raft of people I would otherwise never have meet (Natalie, John, Jason, Tim, Dan, Gary, Jessica, Mark, and many others)

I am not going to forget or fail to repay that.  I’m not sure what kind of ODTUG role I will be able to carve out in future but even if it’s stuffing bags at Kscope17, I’ll be involved.

I’m not dead yet

I want to finish my work with the EPM community initiatives – you have elected me to do that.  Once that is done, it is time for someone else to come onto the board for the first time and go through his process of learning and contributing.

Until that time, I look forward to serving every single member of ODTUG.  Thanks again for believing in me.

Be seeing you.

An Essbase ASO procedural calculation too screwy to be true

But it is

Tim German and I presented at Kscope14 on ASO Planning.  As part of the use case for that presentation, I wrote code that mimicked BSO Planning’s fx (I seem to have currency conversion on the brain, cf. my last post).  You can read all about the power of ASO procedural allocations here:  Calculation Manager, BSO Planning, and ASO Planning combine for an awesome ASO Essbase procedural calculation hack -- Part 3.

What I didn’t cover in that presentation is something I don’t really understand (although I have high hopes that this blog post will spur explanations):  increasing the scope of an ASO procedural execute allocation slows down the calc (so this is pretty self-evident), but decreasing the scope (so far, this makes sense) and and then combining the multiple procedural allocations speeds up the calc (so not quite so self-evident).

There are Doubting Thomases out there, and I completely understand their skepticism given how odd this finding is.  I too was amazed, and would be equally doubtful given the claim.  I’m not from Missouri, but I completely believe in proving what I state.

The numbers

Given the same database, same data, and same general code with the only difference being the range of the Accounts dimension within the execute allocation POV, I get the following times.

Split code line

Single code line

The analysis

Just in case you aren’t following this, that’s the same set of data at 111,222 cells but 32.944 seconds for three execute allocations in a row versus 134.581 seconds.  That’s a difference of 101.637 seconds.  The repeated code is four times as fast as the single code line.  Weird, eh?

The code

For those of you who don’t believe me (and hey, why would you?), here are the logs straight from MaxL:

Split code line

MAXL> execute allocation process on database T3_ASO.T3_ASO with

  2> pov

  3> "CROSSJOIN( {[FY07]},

  4> CROSSJOIN( {[Final]},

  5> CROSSJOIN( {([Actual])},

  6> CROSSJOIN( {([No fx])},

  7> CROSSJOIN( Descendants( PERIOD, PERIOD.Levels(0)),

  8> CROSSJOIN( { (Descendants( [Net Income], ACCOUNT.Levels(0)))},

  9> CROSSJOIN( Descendants( Product, Product.Levels(0)),

 10> ( Descendants( PostCode, PostCode.Levels(0)) ) ) ))))))"

 11> amount "([MTD USA])"

 12> amountcontext "([Local])"

 13> target "([MTD])"

 14> range "{([USD])}"

 15> spread;

OK/INFO - 1300006 - Essbase generated [61523] cells.

OK/INFO - 1013374 - The elapsed time of the allocation is [2.197] seconds.

OK/INFO - 1241188 - ASO Allocation Completed on Database ['T3_ASO'.'T3_ASO'].

     essmsh timestamp: Wed Oct 22 07:39:25 2014

Assets

     essmsh timestamp: Wed Oct 22 07:39:25 2014

MAXL> execute allocation process on database T3_ASO.T3_ASO with

  2> pov

  3> "CROSSJOIN( {[FY07]},

  4> CROSSJOIN( {[Final]},

  5> CROSSJOIN( {([Actual])},

  6> CROSSJOIN( {([No fx])},

  7> CROSSJOIN( Descendants( PERIOD, PERIOD.Levels(0)),

  8> CROSSJOIN( { (Descendants( [Assets], ACCOUNT.Levels(0)))},

  9> CROSSJOIN( Descendants( Product, Product.Levels(0)),

 10> ( Descendants( PostCode, PostCode.Levels(0)) ) ) ))))))"

 11> amount "([MTD USA])"

 12> amountcontext "([Local])"

 13> target "([MTD])"

 14> range "{([USD])}"

 15> spread;

OK/INFO - 1300006 - Essbase generated [23466] cells.

OK/INFO - 1013374 - The elapsed time of the allocation is [14.45] seconds.

OK/INFO - 1241188 - ASO Allocation Completed on Database ['T3_ASO'.'T3_ASO'].

     essmsh timestamp: Wed Oct 22 07:39:40 2014

Liabilities

     essmsh timestamp: Wed Oct 22 07:39:40 2014

MAXL> execute allocation process on database T3_ASO.T3_ASO with

  2> pov

  3> "CROSSJOIN( {[FY07]},

  4> CROSSJOIN( {[Final]},

  5> CROSSJOIN( {([Actual])},

  6> CROSSJOIN( {([No fx])},

  7> CROSSJOIN( Descendants( PERIOD, PERIOD.Levels(0)),

  8> CROSSJOIN( { (Descendants( [Liabilities], ACCOUNT.Levels(0)))},

  9> CROSSJOIN( Descendants( Product, Product.Levels(0)),

 10> ( Descendants( PostCode, PostCode.Levels(0)) ) ) ))))))"

 11> amount "([MTD USA])"

 12> amountcontext "([Local])"

 13> target "([MTD])"

 14> range "{([USD])}"

 15> spread;

OK/INFO - 1300006 - Essbase generated [26133] cells.

OK/INFO - 1013374 - The elapsed time of the allocation is [16.297] seconds.

OK/INFO - 1241188 - ASO Allocation Completed on Database ['T3_ASO'.'T3_ASO'].

Single code line

MAXL> execute allocation process on database T3_ASO.T3_ASO with

  2> pov

  3> "CROSSJOIN( {[FY07]},

  4> CROSSJOIN( {[Final]},

  5> CROSSJOIN( {([Actual])},

  6> CROSSJOIN( {([No fx])},

  7> CROSSJOIN( Descendants( PERIOD, PERIOD.Levels(0)),

  8> CROSSJOIN( { (Descendants( [Net Income], ACCOUNT.Levels(0))), (Descendants

( [Assets], ACCOUNT.Levels(0))), (Descendants( [Liabilities], ACCOUNT.Levels(0))

)},

  9> CROSSJOIN( Descendants( Product, Product.Levels(0)),

 10> ( Descendants( PostCode, PostCode.Levels(0)) ) ) ))))))"

 11> amount "([MTD USA])"

 12> amountcontext "([Local])"

 13> target "([MTD])"

 14> range "{([USD])}"

 15> spread;

OK/INFO - 1300006 - Essbase generated [111122] cells.

OK/INFO - 1013374 - The elapsed time of the allocation is [133.581] seconds.

OK/INFO - 1241188 - ASO Allocation Completed on Database ['T3_ASO'.'T3_ASO'].

Conclusion from the data

I have a few, although they are not satisfying:

1. Those results are freaking weird.
2. Something is going on within ASO Essbase that makes the multiple code lines faster.
3. I wish I was smart enough to know the answer to point number two.
4. Someone will be smart and knowledgeable enough to figure this out.
5. General rejoicing will occur on the completion of point number four.  I will cheer the loudest.

A plea for help

I’m not enough of a scientist to delve into the why (I do try, somewhat, to have a life) nor am I smart enough to figure it out.  Dan Pressman is working on this and he is way smarter, and even more obsessive than me, so we all stand a very good chance of finding out why this is so.

Dan did address this in the Network54 thread, and wrote:

The allocation POV is required to be a symmetrical area of the cube. I know this because I tried some tricks with filters and nonemptytuple using <dimension>.currentmember. To understand this suppose I had a cube with the dimensions FloraOrFauna and Species (among others). Well we know that there will never be tuples such as (Flora, Canine) or (Fauna, ChristmasTree).

Looking at the whole we can not eliminate Canines just on the Flora side because that would be non-symmetrical. That is what using leaves and nonemptytuple is faced with. However if we split the allocation into a Flora allocation and a Flora allocation then we are ok.

 
I believe that Dan’s explanation correctly states that fewer and smaller allocation POV ranges are faster than large ones.  

What I do not understand (but am waiting with bated breath for) is an explanation as to why multiple small POVs that when combined equal the size of the full POV set are faster than a single full POV definition.  As you can see from my statistics, the number of addressed cells is the same.

It just don’t make sense.

I look forward to the explanation.  :)

Be seeing you.