Monthly Archives: May 2015

Tips

Murex logs and nothing to do with lognormal

When you work with Murex, it is likely that you will encounter issues. (if you don’t you’re indeed very long sighted or you should definitely buy some lottery ticket).

Anyway, it is very likely that you will soon end up in the logs directory of the app directory and then what… You have the launcher logs, process pids, many folders, etc… Knowing which logs to open or check is quite daunting but fortunately Unix/Linux has so many tools to do the search for you that you’re in for a treat.

When browsing the logs, you have  2 best friends : a more experienced consultant (if he has a PAC background, you definitely need him as a friend) and… Google! Google is my go-to whenever I have question as to how to find something based on any criteria.

Example:

Last night I was running our EOD script and wanted to check the answer files which had terminated successfully. Quick google search (“how to find files containing string unix”) and I got: fi

find / -type f -exec grep -l "text-to-find-here" {} \;

Transformed it into:

find . -name '*answer*' -exec grep -l "Successfully" {} \;

Well, it worked but then I realize that I actually only cared about the ones which failed and that was getting too painful to do it myself (I was also getting tired which does not help). Another quick google search and

find .  -name '*answer*' -exec  grep  -H -E -o -c  "Successfully"  {} \; | grep 0

And it gave me the list of logs which failed making it much easier to investigate the failing ones.

So that was my example for end of day. But you could also find the files which were modified in the last 5 minutes, narrowing down a lot the number of items to browse through.

find . -cmin -5

And then you can do another search for OutOfMemory or similar if the filename/filepath is not enough to tell you which logs you should check.

And I would recommend to have a go through the logs quickly. If indeed you can’t find anything, of course you can call in a friend as there is no 50-50 or ask the audience sort of joker. My problem with calling in a friend, is that it gets always more tempting as a quick way to solve a problem and you don’t build up your skills as much.

What’s more frustrating than having a problem, calling Murex and checking the very first file: <servicenamelogfile>.log and get : user XXXX not authorized to log in? (or any similar error which could have been fixed in 2 minutes once you have the error cause).

What about you dear reader? Any other command/tips you would recommend?

Tips

Reconciliation or rec – what should I do for my trades

Whenever migrating or updating, one task will consume a fair bit of manpower: reconciliation.

When doing trade reconciliation, the following is to be checked:

– Financial trade details reconciliation. This is usually the first one as it will be used afterwards as the key for reconciliation. In that task, you ensure that trade numbers, deal type, price/rate, portfolio, etc… all the data considered financial is correct.

– Cash flow/P&L/Sensitivities. You normally need to rec all 3. In my experience, it tends to be better to start with P&L (less figures to check, 1 trade 1 number). Then move on to Cash flows, depending on the DB side, you sometimes need a very good tool capable of handling loads and loads of lines. Finally sensitivities. For that one, I would recommend against trade by trade reconciliation. It is too demanding, use a top down approach.

– Non financial reconciliation. This one is a bit up to you. If you have some reports which extract that data, this reconciliation could be considered done. If you do not reconcile it (or even fully) this is the kind of data that can be easily updated post go live.

Reconciliation is a very heavy task. It is demanding in manpower and you need people comfortable with the both applications (the old and new ones). It is as essential to have a good tool capable of assigning defects to trades matching a certain pattern and to re-apply the root causes when performing another rec.

While I don’t think anyone really enjoys doing reconciliation and browsing through lines and lines of breaks, it is an excellent exercise. I often included more junior people to the task as it gave them a chance to go through the different screen, understand how different figures are being calculated. Of course, you cannot leave them alone to do it but they can contribute to the effort and afterwards they will have built a good understanding of the issues and the application which is perfect if they need to support it going forwards.

Feel free to share your tips and bits about reconciliation!

Info

Murex user group

Today a quick post about Murex user group (http://murexusers.org/). As I wrote before, I found it a great idea but it is mostly oriented jobs. Definitely go there and sign up to their linkedin group, if you haven’t already done so.

I tried to give here a higher focus onto expanding Murex knowledge, give new tracks for people to think about and hopefully raise Murex expertise across the board.

But if you believe I could something differently/better, etc… let me know, I’m a firm believer that one could always improve!

Tips

Datamart fun

6 Comments

Datamart is a great tool in Murex but it also quite confusing as to how to use it and make the most out of it. As always, your Murex consulting team is the best source of advice.

The process to produce reports is usually the following:

  1. Define Simulation view with the data you want to retrieve
  2. Define a Dynamic table based on that Simulation view (note that you could base a dynamic table directly on TRNRP_PL or TRNRP_CS for instance)
  3. Define a feeder on that dynamic table  (this will store the results into the reporting DB)
  4. Then use an extraction to retrieve the data from the reporting DB into a viewer.

The feeder can also source data from Murex tables or from other reporting tables. You’ll just have to build a map of the data you need and how to best access it. The feeders with SQL can retrieve data from different tables.

The advantage of using the simulation view as the source is that you can easily add fields and in a way do some WYSIWYG (what you see is what you get).

Now when designing reports, it is important to decide how frequently you would need to run the reports. For instance, if your feeders call upon other reporting tables, these ones won’t be refreshed. So re-running the reports on request is probably not always possible. Again it depends on your setup. If you’re simply sourcing from a dynamic table then it won’t apply to your case, but again each reporting setup is different.

Now one of the best feature of the reporting in Murex is the job recovery. If some of your report generation fail, from the job recovery you can re-run the report on the failed subset.
It might take many iterations but in the end you will end up with the failed trades. You can then exclude the failed trades or investigate them.

It can be used as a great tool to test if the EOD will run ok and zero on the trades that might cause issue.

Then of course, once you have your datamart running and all is good, what you need to build is the proper view/layout but that’s a different lesson.

What about you? Any good tip to share?

Food for thought

Murex and Excel – a love hate relationship

4 Comments

Murex and Excel have always had this love-hate relationship and I found interesting how it involved over time:

On one hand, you have Murex, secure application: access to DB is controlled, access to the data is controlled, audited. The system is quite flexible but nowhere near Excel.
On the other hand, Excel is agile, flexible to the extreme and highly configurable : librairies, ODBC connections, Reuters plugin, etc. No wonder it is the bank’s preferred tool.

The bank problem with Excel is about critical processes: overengineered if too many users contribute to it, not properly maintained if the right person left or is on vacation. You sometimes end up with unstable spreadsheets or incorrect calculations: Excel is too flexible, impossible to control and the bank could be running major risk falling outside its control.

But the users are not easily willing to give up on Excel flexibility and ease of use (everyone knows how to use Excel, even my mom!)

So it’s no wonder that Murex has been trying to offer more flexibility, more functionalities to bridge that gap. Let’s have a look at what exists/existed:

– Excel link. At the start of Murex java version (Mxg2000), there was a functionality to link the current Murex screen to excel. One could link cells from Murex into Excel. The problem is that the screen needed to be opened in Murex (the linkage was done at client level) at the same time than Excel. And there were also couple of bugs. In the end, I don’t think it was ever really used and it died away

– Reporting API. One could trigger dynamic tables and get the results in Excel. It was like automating the report run and retrieval of data.

– Simulation API. More interesting, this one is actually quite old and you could access some simulation functions and results into Excel. Not so well known, it was actually quite useful till…

The viewer came in. I think this was the most interesting move in the Murex saga to bridge the gap. The viewer took a lot of work and investment to be what it is today (and it is still changing). And while it is like a pivot table with all Murex data, users are sometimes frustrated that the tool is not as flexible as Excel. It feels like Excel, smells like Excel, but it is not and users might forget this.

The one that everyone wonders about it is a GUI based on Excel. I won’t comment too much on that one as to what will or will not be released. Murex has to always be wary that it is a secure platform (sorry to repeat myself, over and over!) and giving flexibility should never come as limitation to security.

Today I’m a strong believer that most processes should be integrated into Murex, away from Excel. If a process is critical for the bank to run, it needs to be owned and acknowledged by the bank. And if you believe that Murex might not be able to replace Excel on a particular process, I would still suggest discussing it with them : Murex people love challenges!

And you dear reader? What do you think of Excel in the bank?

Jobs

Murex performance – is the system slow?

5 Comments

Murex performance: Is my system slow or is it just me? When you present the system to new users, it is a question you often hear.

There are many answers which can come up:
– Yes
– No
– Maybe
– Server is a little small
Etc…

But the only good answer is: “It’s all relative!”.  Indeed, what do you call slow or fast mostly depends on the user.
For instance, if opening a trade ticket takes 3s, is that slow? is that fast? Agreed, if it takes 2 minutes, it is slow!

So the problem with performance is that there is a big amount of subjectivity. But I don’t want to pretend or even try to do psychology and check what the human mind considers slow or fast. On the contrary, I’d like to take precise examples of what users frequently report:

– Actual session start. Since the new GUI, login, password, group are almost instant, but the actual session start when you enter a menu usually feels slow
– Opening details: bonds, trades, counterparts, etc…
– The feeling that the system is sometimes a bit sticky, where actions take 1s or so when you expect them to be instant
– Simulation loading
– Accounting generation
– Saving trades

There are, in my opinion, 2 types of Murex performance issues: the user experience type and the structural ones. One could argue that they’re both the same but let me explain:

The UX ones are the ones which 1s or 2, for which timing is hard or imprecise. In the list above, I’m referring to opening details, stickyness. This is usually this type of performance which is ignored as 1s to open a trade or .1s does not seem like a big change to the user. But what the user does not always understand is that when you press space bar to open a deal, lots and lots of things are happening in Murex: the trade number is sent from the client to the application server. And then the application server is sending DB requests to get all information. It is not one single request, we’re closer to hundreds than few ones: get trade header, get trade body, get contract details, get additional flows, check access rights. If we assume that the communication between the DB and the application is 3ms, 100 requests bring that to .3s, add the CPU time (to decide if the trade is part of a package, requires to open other tables), add actual request time from the DB and then sending all the information back to the client. And here you go 1s, 2s are very easily reached.

So the User Experience performance issues are also structural and there’s not much to do in terms of code optimization. (well, at least not in my non PAC-brain).

The actual structural ones, the ones you expect to be slow are basically like the above compounded many times, factored with extra calculation for risk. The good thing is that when you get to that level, you can usually find optimizations on the DB side when not on the code side to improve speed and loading/processing more information at once. Usually when you can contact support for Murex performance, people expect to help on this kind of issues.

So back to our original question: is the system slow? It is indeed relative. There are implementation of Murex where the system is lightning fast. But everything has been optimized with that objective. To get your ping times from 1ms to .1ms is no small feat, to have a large DB and very fast requests require massive and optimized DB power, etc… So it can be done and has been done, but people tend to be cost sensitive, so doubling (well, I suspect far more than doubling) your hardware/maintenance budget so that a trade does open in .1s instead of 1s does not really make sense.

And Murex also works hard in terms of improving the user experience where they can: Livebook is a great example. Livebook means that data is churned all day long by processes so that when you enter Livebook in place of simulation, you don’t wait 5-10 minutes but some seconds to have the information; screenset is another great example, defining screensets lets you have all the sessions you need opened in one go rather than starting them one by one.

To conclude, Murex performance is addressed where Murex can do something or think of something innovative. But there are some limits due to hardware that are next to impossible to improve from a Murex point of view. So Is the system slow? No, Murex worked and is working hard on it but in the end, it all depends on your implementation and how fast you want (can afford) it to be.

Friday funnies

Undocumented feature

This Friday, a small essay as to what all of us have one day experimented (maybe not that extreme though). I hope you have as much fun to read as I had to write it.

Working hard and all day long,
John was alarmed when the system returned:
"Unknown error"
Shocked he was and there was nothing else to do 
Than to press Return. The following message
sent shivers down his spine
"Your session will now close"
"No!" He shouted at the computer screen.
Sadly, computers are made of silicon and plastic
And despite his rage, the message was still there unaware of John's distress.

After giving that formula all his love, strength and energy 
of the day. Putting in comments as taught by his teachers
Naming variables clearly and smartly.
The bold message was still there as an omen to the inevitable:
"Your session will now close"
Now sweating and trembling with fear, he quickly grabs his phone
Dials the Murex support line and get in touch with his favorite
consultant. Surely, something can be done. 8 hours of work cannot be lost so easily!
Finally, a voice, something human in this inhumane process. Quickly he stammered his problem. His nerves were getting the better of him. He was going down, he knew it. His last light in the darkness of his mind was this Murex consultant.
The response was not at all was he expected
"Ha ha, it seems that you've encountered an undocumented feature! I hope you did save your work beforehand
- Undocumented feature? You mean it is a bug? My work is lost?
- I'm afraid so. May I help you with anything else?"
Sadly for that poor consultant, his eardrum would be torn by the loud NO that John threw at him in all his rage.
John now almost crying, accused of bringing his own downfall. How could he be accused that this problem, this undocumented feature, this bug could be his fault by not saving?
Bringing back primal feelings from the dawn of humanity, he grabbed the medium he used to communicate with that impotent consultant and focused all his rage into throwing it into the screen. Instant relief!
The afterfall... the shame of a broken screen. The good aspect of working late: he did not have to bear the stare of other people. Replaced his screen, restarted his computer. His favorite software booting back up, even if it went down few notches in his book, and John is working again.
Word to the wise: no matter how much you love Murex, always backup formula in Microsoft notepad (notepad ++ is ok as well!)
Tips

Naughty naughty spreads

It happened to me (again!) yesterday. The curve spreads are naughty naught critters!

Let’s explain:

In some cases, the curve spread indicator (the small 1 or 2 on the left of the market quote) is sometimes bugged and does not work properly. Usually nothing to worry about as it is quite easy to see if there are spreads or not (just need to play with the combo box on the far right).

Unfortunately when you’re working on a new environment or with rates which source is not clear to you, they’re not always your first target.

So what happened? (I know this story is more thrilling than a Stephen King book (yep, just compared myself to Stephen King just like that))

Basically a curve was not calibrating and I followed my previous post steps to understand what was going on. Removing curve spreads, reducing the number of instruments (the quotes were ok). Finally it was calibrating to a crazy rate (-50%). Could not understand why, market quote was correct. Tried to overtype the zero rate and got a crazy market quote.

As the instrument had the market quote as a margin on the secondary I was suspecting that something was amiss there. The pricing maybe was reading incorrectly the margin. Started to look at other curves to see if the problem was there as well, but everything was ok.

So went back to my curve and somehow (imagine a spot light above my head) started to check my curve spreads! Et voila, eureka moment, there were convexity spreads (in the range of -50%). Zeroing them brought everything back inline, the curve calibrated ok, problem solved.

As usual with these kinds of problems, even if you’re proud to have solve the issue, you always feel bad not to have checked the guilty part first!

What about you dear reader? Any similar experience?