Wednesday, June 29, 2011

The Secret M8 Papers


They lied to us.  And now we have the proof.  

Last winter when Metro-North was in full melt-down (or freeze-up), commuters asked over and over again, “Where are the new M8 cars?”  The constant reply from the railroad and CDOT was “the testing continues apace… be patient.”  But The Commuter Council had heard otherwise.  Whistleblowers were calling and e-mailing us saying there were serious problems with the M8s.
So, for the CT Rail Commuter Council’s February 2011 meeting, we asked Metro-North and CDOT to bring representatives from the M8’s designer and manufacturer, Kawasaki, and engineers from LTK, the consulting firm being paid $27 million to test the cars.  We wanted to ask them what was going on.  But CDOT refused.  Appeals to newly elected Governor Malloy fell on deaf ears.  At the Council’s meeting the then-interim CDOT Commissioner said we were not smart enough to understand what the engineers would explain.  Oh, really?

Now, thanks to an FOIA (Freedom of Information Act) filing by WABC-TV’s Jim Hoffer, we have seen a treasure trove of e-mails and letters between Kawasaki, LTK and Metro-North detailing countless problems and delays during this period.

For perspective, remember this timeline:  the first M8 car arrived in New Haven 12/24/09 but the first M8 train didn’t go into service until 3/1/11.  What happened over those intervening 15 months?  Testing, a lot of delays and excuses.

The “M8 Papers” show letter after letter from Kawasaki appealing for delays in testing.  Excuses range from sub-contractor bankruptcies to 20 days needed to load and unload dummy weights from test trains.  Kawasaki’s Project Manager even blamed the weather for testing delays in the final weeks before the M8’s finally saw service.

Metro-North responded, “Why does snow stop the tests?  It was not that much (snow) and we expect to operate in all weather conditions short of hurricanes and over 2 ft of snow.  An aside, anything less than 6 inches (of snow) is a frost.”

In January of this year, CDOT told the Commuter Council that computer problems had been found during testing.  A day before that meeting, LTK wrote in an e-mail “Kawasaki has yet to accumulate a trouble free mile” in testing.

This mantra of “software problems” would be the ongoing excuse whenever anyone asked about the M8 delays.  But the problems were far greater than just software.
A January 24, 2011 four-page e-mail from LTK says testing turned up over 150 problems ranging from the doors to air compressors, from the brakes to the ‘dead man’ switch.  Even the hand-dryer in the bathroom malfunctioned.  Pantographs wouldn’t go down enroute to GCT.  Emergency brakes applied without notice.  The M8s horns even got frozen.
Kawasaki kept asking for more time, presumably to avoid costly fines for ever-increasing delays in getting the M8’s in service.  January 3rd of this year Metro-North had to cancel a planned nighttime test because Kawasaki personnel didn’t show up. “It would have been nice to know this before we had an extra train crew and special duty engineer show up for work,” wrote Metro-North.

Today there are three M8 train sets in service.  So far they’ve encountered few problems.  But production delays in Japan and Nebraska mean we’ll only have 60 cars in service by year end.
But how could such a trouble-plagued prototype suddenly become the darling of the fleet?
For that question, we still don’t have the answer.  You see, “The Secret M8 Papers” are not complete.  Even though it took WABC-TV’s “Investigative Unit” four months to unearth hundreds of e-mails and letters, Metro-North has yet to release the final documents from the crucial February 2011 testing.

One wonders what they will show.

Monday, June 13, 2011

Travel Rage

I’m a big guy.  Not self-important, but large.  So when I’m riding Metro-North at rush hour and the only available seats are those dreaded middle seats in the three-seat rows, I’d rather stand.  Why inflict my girth on two fellow passengers and make three of us uncomfortable instead of just one (me)?
Taking public transportation is a compromise.  We all must give a little and share the same space, sometimes in much closer proximity than we’d like.  Sometimes this can lead to conflict.
Consider the following cases, all true and all from just the past few weeks:
First, the recent video of a “loud woman” being kicked off a Metro-North train for cursing and causing a scene when the conductor asked her to stop.  This video, shot on a cell phone by another passenger, had a half-million hits within 24 hours, turning a minor incident into a huge embarrassment.
Or how about this?  On an eight-hour flight from the UK to the Barbados, a fist-fight erupted involving a dozen passengers.  Half way across the Atlantic, a group of passengers celebrating “something special” got into a fight with another passenger who complained that they had cursed in front of her child.  The verbal attacks quickly turned physical with fists flying.  It took other passengers and crew a half-hour to quell the melee.  Barbados police arrested the trouble-makers on landing.
Or consider this episode:
A United Airlines jumbo jet bound from Washington’s Dulles airport to Ghana (Africa) had to turn back when passengers got into a slap-fest over leg-room.  One passenger reclined his seat.  His neighbor behind him protested, but the reclining passenger did nothing.  So, the suddenly-cramped passenger smacked his selfish neighbor.  Other passengers tried to intercede, but the crew decided to turn back to DC after dumping 16,700 gallons of fuel and requiring an escort (at taxpayer expense) by two F-16 fighter jets.
Or on the domestic front, how about the recent Jet Blue flight from Florida to Boston where a man, having trouble stowing his luggage under his seat, literally slapped a flight attendant?  He was arrested.
Or on the rails, how about the woman sitting in an Amtrak “Quiet Car” who yapped on her cell phone for 16 hours, refusing to observe the rules or move to another car?  She was arrested, later complaining that she felt “disrespected” by the incident.
Alas, it’s hard to find out what ultimately happened to these folks, though I think that a little jail time, a hefty fine and life-time inclusion on the “no flight list” would seem appropriate.  Publicizing their punishment might go a long way toward deterring someone else from similar boneheaded behavior.
In the words of Rodney King… “Can’t we all just get along?”
It’s unlikely that the airlines will ever give us more legroom.  And the stress of travel will never go away.  Short of slipping everyone a Xanax before the flight, can’t we all just chill out this summer and get to our destination?
For those of you who can summon a private jet, enjoy!  For the rest of us suffering in coach, let’s just learn to be civil.

Saturday, June 11, 2011

Dauphine stage 6

Not alot of exciting news to report today unfortunately. Just like yesterday we set of at a frantic pace up and down mountains again causeing splits left right and centre, after 80km a group finally got away which our team had mauro finetto. When a start is like it has been over the past few days to be in the break you have to be very strong as first you need to stay in the front as and today's group formed from a front group of no more than 50riders it is a big achievment simply entering in the days great escape. I had a quiet day in the bunch just doing my usual thing of looking after ivan. Had a little bit of chaos on the decent to final climb with only 20km to finish with first a puncture but while i was riding back though the cars to get to the front a few cows had decided to jump into the peleron while it was traveling at 80kmph and as you can imagine the end result was not pretty. By the time i arrived on the seen there were a few unlucky dudes on the ground and also of the side of the road in the paddock that should have been occupied by the cows. As often to any living thing when its scared, the natural impulse is to poo ones self. There was no exception in this case so not only was there a bunch 1 tonne moo cows charging down the rd between cars motorbikes and cyclists and all the hoopla that goes along behind a bike race but also a monumental amount of poo everywhere. Fortunately for me i was able to arrive at the scene of the carnage and avoid cars riders and perhaps most fortunately to piles of poo!

Of course the crash caused some chaos is the bunch and inevitable split so although i was back in a group of sorts i was now faced with a frantic chase to get back to the front group with only a few km's to the final climb. This was particularly importand as i had in my possesion the all important final water bottle for ivan to keep him suatained on the final climb. So a few crazy corners and some super high rpm revving and i made it to the front about 500m before the climb started, delived the bottle into the climb we went, i put up my parachut and went backwards at a rate of knotts and just to add insult into some very tired legs i flatted again just as the first set of cars had roled on past me to follow the lead group. So was not ment for me today, i put the call out for the second car to bring me a wheel but it was a fair ways back down the mountain so i just trudged up the first 5km of the climb on the dud wheel until paolo arrived with a replacement. Anyways all in all was another good hit out of a day and some days the luck just does not smile on you, hopefully tomorrow will be a little kinder.

The facts and figures for the stage from my srm are as follows

Distance 192km
Time 5hrs 20min
Speed av 36kmph
Elevation gain 4000m
Watt average 275
Heart rate average 145.5
Energy exp 5300kcal

So basically it was another jolly solid day which is good because thats what i am here for, give the body a bit of a wake up call

Time for a good sleep

Cjw

Sent from my BlackBerry® wireless device

Dauphine stage 5 srm data

Yesterdays srm data



Time 5hrs 6min

Distance 211km

Speed av 42kmph

Elevation gain 3000m

Watts 289av

Heart rate 152av

Energy exp 5200kcal



Greeeaaaatttt training



All aboard the pain train for another day in the alps!!!



Cjw

Sent from my BlackBerry® wireless device

Friday, June 10, 2011

Dauphine stage 5

The first day in the mountains was quite an adventure for me. I had high hopes of going in the days breakaway but unfortunately so did a majority of the peleton. As so often happens in this case there are so many attacks that nothing forms for a long long time until a cease fire is called. This insured today and after 98km one man, jason mc cartny from radio set in in a solo pursuit for glory. Now the route to this occurring was quite an unenjoyable experience for me. On the first climb of the day after just 45km i had already fired a few fatefull useless bullets in attempt to get up the rd. I had arrived at the climb already on the rivit and as it occured just over 12months ago in a race in italy under pretty much the same circumstances i suffered from another asthma attack. So i cant breath but not to worry as fortunately it occurred only 2km from the top of the climb so i started to sand bag back through the bunch to see the doctor, off course due to serious pace the peleton had split and it did not take long for me to fall out the back and of course there was no doctor to be seen. So i am in the second group and try and ignore my breathing for a bit as our small group tries in vein to re enter the front group but to no avail. Next thing the doctor flies by to get to the front group so now i cant breath and have been dropped to the second group so no option but to suffer in silence and take as deeper breaths as possible in the hope that not only we get back on but also i see the doctor's white coupe again! The problem with the asthma/allergy attack is not really the breathing difficulty, well this is a pain but without being able to breath properly you cant get oxygen to the muscles so firstly your going flat out, second you cant breath and 3rd your legs are just gradually loosing more and more power with every pedal stroke so is not ideal experience for the first half of a cycling race! Fortunately after 100km we rejoined the front group and with my eyes firmly on the doctors fancy car i bee lined to it and promtly explained my predicament. Being a very experienced race doctor he simply said he did not think it was asthma but more likely allergy which i had suspected last time it occurred however i was subsequently diagnosed with asthma on that occasion. He gave me an simple anti histamine and sent me on my way. I spent another 50km or so regaining myself a little after the mad first half of the race and started to feel better. By the start of the final climb it had taken me 200km to get to the front but i finally did and amazingly i could breath perfectly and had no dramas Stalin in the front of the main field on the final climb. I was pretty jolly excited at this developement not solely because i was feeling good in the mountains again but a problem that has bugged me for quite a few years was finally solved by the race doctor and a little pink pill.

So to the race, i just assumed my usual role and stayed close to ivan at the front of the group to help him if required and when the hitters lit up the gas with a couple of km to go i realised unfortunately that the fatique from early in the stage had not completely left my aching pins and with ivan safely in the front i sat up to save some bullets for tomorrows very very very difficult mountain stage. I hope a day that should not have the same crazyness of today on my part and a day where i can contribute alot more to the team. It certainly is a relief to have solved this allergy issue that is for sure.

I think the most exciting developement of the day was the clearly evident return of condition for our tour de france captain ivan baSso. He had no trouble staying with the big favourites and rest assured he is going to keep getting alot stronger in the coming days and weeks in training and show why he is such a great cyclist.

So pretty excitning day on all fronts as it certainly finished alot better than it started i am looking forward to getting stuclk into it tomorrow.

Cjw

Sent from my BlackBerry® wireless device

Thursday, June 9, 2011

No Exit (but not in MaxL)


Introduction

In “No Exit”, that French existentialist philosopher had it wrong, or he would have had he confined his thoughts to the awesomeness that is Essbase’s MaxL.  Or, to paraphrase that other French philosopher, had he cultivated a MaxL garden, life might not have seemed so bleak.

Surely when Sartre wrote “Hell is other people” he was just frustrated with the way MaxL (we know that all philosophers are at heart Essbase hackers, and all Essbase hackers are at heart philosophers – I’m not reaching too much, am I?) handles exiting out of a script, especially when there is an error.

Error handling in MaxL pre 11.1.2

The iferror and define label keywords have been in MaxL since almost the very beginning (I think they came in in Essbase 7, although MaxL got its first start in Essbase 6.5 – anyone who knows differently please write in care of this address).

iferror

To quote My Very Favorite Bit of Essbase Documentation (MVFBED) aka the Tech Ref, iferror can trap:
  • Errors in MaxL statement execution
  • Errors in MaxL Shell command execution, including:
    • Errors in spool on/off, such as permission errors
    • Errors in set column_width, such as invalid widths
    • Errors in script nesting, such as permission errors or nonexistent include files

Note that MaxL is not going to trap data or dimension load errors.  ‘Twould be nice if it could, but it doesn’t.  So it goes.

define label

iferror branches to a label as defined, logically enough, by the define label keywords.

Two great tastes that taste great together

Use iferror to branch to a label and then immediately quit the script; those labels are created with define label.  Simple, right?

A practical example

When I write MaxL code, I want the script to stop if it hits some kind of monumental error as continuing a process that has badly failed will likely only make things worse.  

The iferror statement only tests the precedent statement for error, so unlike more sophisticated languages MaxL can’t just declare error handling on and a single place to catch the errors.  Remember, an statement that results in error followed by a successfully executed statement clears the error state.

What I end up doing is literally sticking an iferror after every statement.  Yes, every statement.  It looks ugly but it works (sort of the story of my coding life).  Here’s an example:

/*
Purpose:    Run calcs
Written by:    Cameron Lackpour
Modified:    A long time ago
Notes:       
*/

/*    Log in to Essbase    */
login admin password on localhost ;
iferror "ErrorHandler" ;

/*    Define STDOUT and STDERR outputs    */
spool stdout on to "c:\\Automation\\Sample\\MaxLLog\\mshSample.log" ;
iferror “ErrorHandler” ;
spool stderr on to "c:\\Automation\\Sample\\MaxLError\\mshSample.err" ;
iferror "ErrorHandler" ;

/*    only supervisors and developers may connect    */
alter application Sample disable connects ;
iferror "ErrorHandler" ;

/*    Run calculations    */
execute calculation Sample.Basic.AdminAgg ;
iferror "ErrorHandler" ;

execute calculation Sample.Basic.OrgAgg ;
iferror "ErrorHandler" ;

/*    Allow all users to connect    */
alter application Sample enable connects ;
iferror "ErrorHandler" ;

/*    Error handler label    */
define label "ErrorHandler" ;

/*    Leave the MaxL shell    */
logout ;
exit ;

A better way in 11.1.2.x

There’s nothing new with iferror and define label as they work the same way as before.

However, the exit statement now has a new piece of functionality that it didn’t have before 11.1.2 – the ability to pass a condition code on exit.

exit

Per MVFBED, “You can optionally set the exit status variable to a non zero argument to return an exit status to the parent shell.”

The impact

What does that mean?  Your calling script language is (hopefully) more sophisticated than MaxL in its error handling and branching (I’m looking at you VBScript, PowerShell, and Perl) and can react to the error code(s) you define.  Wouldn’t it be nice if your calling code tried to fix things, or at least told you where (and maybe why) everything went pear-shaped instead of just saying, “It don’t work”?

Some easy examples first

iferror and define label but no defined exit code

Here’s an example that tries to connect with a bad password (an extra s in the word “password”):
/*    MaxL with non-specific error codes    */
/*    Login with bad password        */
login admin passsword on localhost ;
iferror 'ErrorHandler' ;

/*    Create label    */
define label 'ErrorHandler'

/*    Quit MaxL    */
exit ;

Run and response:
Essbase MaxL Shell 64-bit - Release 11.1.2 (ESB11.1.2.0.0B444)
Copyright (c) 2000, 2009, Oracle and/or its affiliates.
All rights reserved.

MAXL> login admin password on localhost ;

  ERROR -     103 - Unexpected Essbase error 1051293.
  ERROR - 1051293 - Login fails due to invalid login credentials.

 MaxL Shell completed with error


When I interactively test the Windows OS errorlevel variable, I get a value of 2.  
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>echo %erro
rlevel%
2

Successful MaxL executions result in 0 errorlevels, failures a 2.  So yes, I know something went bad, but I have no idea what that is just based on the error code.

iferror and define label with a defined exit code

Failure example

Two new things are in this code:
  1. There are two error handlers – one for bad logins, one for everything else.
  2. The error handler that ties to a bad login gets an error code of 10.  


Note that if there is no error of any kind, the code will exit with no defined error code.

/*    MaxL with specific error codes    */
/*    Login with bad password        */
login admin passsword on localhost ;
iferror 'BadLogin' ;

/*    Create label for generic error handler    */
define label 'GenericErrorHandler';

/*    Quit MaxL    */
exit ;

/*    Create label just for login errors    */
define label 'BadLogin' ;
/*    Quit MaxL with a 10 error code    */
exit 10 ;

Run and response:
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>essmsh e:\
tempdir\errortest.msh

Essbase MaxL Shell 64-bit - Release 11.1.2 (ESB11.1.2.0.0B444)
Copyright (c) 2000, 2009, Oracle and/or its affiliates.
All rights reserved.

MAXL> login admin passsword on localhost ;

  ERROR -     103 - Unexpected Essbase error 1051293.
  ERROR - 1051293 - Login fails due to invalid login credentials.

 MaxL Shell completed with error


When I interactively test the Windows OS errorlevel variable, I get a value of 10.  
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>echo %erro
rlevel%
10

Success example

/*    MaxL with specific error codes    */
/*    Login with bad password    */
login admin password on localhost ;
iferror 'BadLogin' ;

/*    Create label for generic error handler    */
define label 'GenericErrorHandler';
/*    Quit MaxL without a predefined error code    */
exit ;

/*    Create label just for login errors    */
define label 'BadLogin' ;
/*    Quit MaxL with a 10 error code    */
exit 10 ;

Run and response:
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>essmsh e:\
tempdir\errortest.msh

Essbase MaxL Shell 64-bit - Release 11.1.2 (ESB11.1.2.0.0B444)
Copyright (c) 2000, 2009, Oracle and/or its affiliates.
All rights reserved.

MAXL> login admin kscope2011 on localhost ;

OK/INFO - 1051034 - Logging in user [admin@Native Directory].
OK/INFO - 1241001 - Logged in to Essbase.


 MaxL Shell completed

When I interactively test the Windows OS errorlevel variable, I get a value of 0.  
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>echo %erro
rlevel%
0

Putting it all together

I will concede in advance that perhaps the below level of error trapping and surfacing of where the error occurred is a bit over the top, but regardless, it certainly traps everything.  Yes, this might be a good time to invest effort in MaxL + Perl as an alternate way to do error trapping.  However, this is a MaxL post, not a MaxL Perl module post, so onwards, ever onwards.
/*
Purpose:    Connect, kick non-admins out, and surface errors based
        on action.
Written by:    Cameron Lackpour
Modified:    Right now
Notes:        *    Illustrate use of exit
*/

/*    Log in to Essbase    */
login admin password on localhost ;
iferror "BadLogin" ;

/*    Define STDOUT and STDERR outputs    */
spool stdout on to "c:\\Automation\\Sample\\MaxLLog\\mshSample.log" ;
iferror "BadLogFile" ;
spool stderr on to "c:\\Automation\\Sample\\MaxLError\\mshSample.err" ;
iferror "BadErrorFile" ;

/*    only supervisors and developers may connect    */
alter application Sample disable connects ;
iferror "CouldNotDisable" ;

/*    Run calculations    */
execute calculation Sample.Basic.AdminAgg ;
iferror "AdminAggError" ;

execute calculation Sample.Basic.OrgAgg ;
iferror "OrgAggError" ;

/*    Allow all users to connect    */
alter application Sample enable connects ;
iferror "CouldNotEnable" ;

/*    Leave the MaxL shell    */
/*    This is where the script exits if there is no error.    */
logout ;
exit 0 ;

/*    Create label for login errors    */
define label "BadLogin" ;
/*    Quit MaxL with a 10 error code    */
exit 10 ;

/*    Create label for log file errors    */
define label "BadLogFile" ;
/*    Quit MaxL with a 20 error code    */
exit 20 ;

/*    Create label for error file errors    */
define label "BadErrorFile" ;
/*    Quit MaxL with a 30 error code    */
exit 30 ;

/*    Create label for disable connects errors    */
define label "CouldNotDisable" ;
/*    Quit MaxL with a 40 error code    */
exit 40 ;

/*    Create label for AdminAgg calc script errors    */
define label "AdminAggError" ;
/*    Make sure that connections are enabled    */
alter application Sample enable connects ;
/*    Quit MaxL with a 50 error code    */
exit 50 ;

/*    Create label for OrgAgg calc script errors    */
define label "AdminAggError" ;
/*    Make sure that connections are enabled    */
alter application Sample enable connects ;
/*    Quit MaxL with a 60 error code    */
exit 60 ;

/*    Create label for enable connects errors    */
define label "CouldNotEnable" ;
/*    Quit MaxL with a 70 error code    */
exit 70 ;


Example of a bad directory

Run and response:
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>essmsh e:\tempdir\maxlwithexit.msh

Essbase MaxL Shell 64-bit - Release 11.1.2 (ESB11.1.2.0.0B444)
Copyright (c) 2000, 2009, Oracle and/or its affiliates.
All rights reserved.

MAXL> login admin password on localhost ;

OK/INFO - 1051034 - Logging in user [admin@Native Directory].
OK/INFO - 1241001 - Logged in to Essbase.

     essmsh error: Unable to open log file c:\\Automation\\Sample\\MaxLLog\\ms
Sample.log
 MaxL Shell completed with error

When I interactively test the Windows OS errorlevel variable, the OS returns 20.  
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>echo %
rrorlevel%
20

Fix the directory

I changed the directories that didn’t exist to ones that did.  So this:
spool stdout on to "c:\\Automation\\Sample\\MaxLLog\\mshSample.log" ;
iferror "BadLogFile" ;
spool stderr on to "c:\\Automation\\Sample\\MaxLError\\mshSample.err" ;
iferror "BadErrorFile" ;


became this:
spool stdout on to "e:\\TempDir\\mshSample.log" ;
iferror "BadLogFile" ;
spool stderr on to "e:\\TempDir\\mshSample.err" ;
iferror "BadErrorFile" ;


Good directory, bad calc script, actually managed to turn connections back on

I’m not going to give every example of what might happen, but this time the code has managed to log in, create log files for STDOUT and STDERR, and disable connections.

However, when it came to run the calc AdminAgg, the script failed because the calc script doesn’t exist.

NB – Based on the error branch, the code can do specific things on error.  In the code, I make sure that errors in running calcs always re-enable connections to the Sample application.  Without these specific error codes, it would be impossible to know that connections need to be enabled.

Run and response:
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseServer\bin>essmsh e:\tempdir\maxlwithexit.msh

Essbase MaxL Shell 64-bit - Release 11.1.2 (ESB11.1.2.0.0B444)
Copyright (c) 2000, 2009, Oracle and/or its affiliates.
All rights reserved.

MAXL> login admin kscope2011 on localhost ;

OK/INFO - 1051034 - Logging in user [admin@Native Directory].
OK/INFO - 1241001 - Logged in to Essbase.

MAXL> alter application Sample disable connects ;

OK/INFO - 1054014 - Database Basic loaded.
OK/INFO - 1054014 - Database Xchgrate loaded.
OK/INFO - 1054014 - Database Interntl loaded.
OK/INFO - 1054014 - Database Sparse loaded.
OK/INFO - 1051061 - Application Sample loaded - connection established.
OK/INFO - 1054027 - Application [Sample] started with process id [7796].
OK/INFO - 1056013 - Application Sample altered.

MAXL> execute calculation Sample.Basic.AdminAgg ;

  ERROR - 1012500 - The requested calc script [AdminAgg] not found.

MAXL> alter application Sample enable connects ;

OK/INFO - 1056013 - Application Sample altered.

 MaxL Shell completed with error

When I interactively test the Windows OS errorlevel variable, the OS returns 50.  
E:\Oracle\Middleware\EPMSystem11R1\products\Essbase\EssbaseClient-32\bin>echo %e
rrorlevel%
50


Were I automating this code for real I would use the calling code to query %errorlevel% and then send specific emails based on the error code.  In this case, I could quickly be informed that there was something wrong with the calc script AdminAgg instead of having to wade through tedious log files trying to figure out what went wrong.

Conclusion

Adding the ability to pass on an error code to the exit keyword seems trivial, but it can provide a lot of information to automation code and make debugging production issues that much easier.  Why aren’t you using it?


Popular Posts