Tag Archives: simulation

PL reports – solutions

Shazmd asked a question through the forum about how to make a report giving out PL as of 3 dates.

There are couple of solutions to this question and which one you need to use is totally up to you 🙂

First thing to keep in mind is that when people mention reports it should not always equal datamart. For instance, simulation is a live report showing the risk and which could fetch data as of couple of days in the past.

Trade query is also in a way a report, with no calculated data. So it is important to understand what is the end user after so you give him/her the most appropriate solution.

  1. User definable P&L notepad

This first solution is probably the simplest and is perfect if the request is just a one off that would not repeat very frequently. User definable notepad is a dynamic table based on PL, there is just a direct menu to access it. So if you search for it (it is under middle office, P&L related procedure (or just type in the search notepad)) and get into it, Murex will ask you to choose a filter. Space bar on the default one. You then see a filter screen. You have 3 dates you can choose from (Inception means not calculated) and you can pick a portfolio or any other criteria. The data for the 3 dates will be computed when you validate the filter.

You then get a matrix will all the deals selected and the data you need. Just change the view to be what you need using Tools-View and choose the columns which make sense. You will see some fields available 3 times, they are the data computed as of the 3 different dates. Just change from description to field name. The field ending in 0 corresponds to the data for the first date selected, the one ending in 1 corresponds to the data for the 2nd date selected and the last one ending in 2 corresponds to the data for the 3rd date selected.

You can then copy paste (ctrl-shift-C to copy all lines) the results or export them from the file menu. You can then work out the data in Excel.

2. Datamart

Datamart for 3 PL dates is the 2nd solution. It is easy to re-use and the format will be up to you.

First of all, you need to choose which engine to use for computing the data (note that it is using the same code underneath but there could be differences in usage). The first one is a dynamic table of type PL (TRNRP_PL). You need to define one and choose the fields you want. Remember that you can test a dynamic table to check if the content is ok. The dynamic table should produced only 1 set of PL result not 3.

Once you’re happy with the dynamic table, you need to wrap it so that it will produce data into the datamart. To do so (and in high speed): you will need to define a feeder and then inject that feeder into a batch of feeders. The feeder will go through creating a table in the datamart and attaching data to it (data coming from your dynamic table). When you define your batch of feeders make sure that you can have at least 1 set per date so that data in the datamart is historized.

Just run the batch of feeders as of the 3 dates you need to compute (you might need to amend the global filter within the batch of feeders to choose which date).  Once your datamart is populated with the data (you can query it and check by SQL for example). You need to build an extraction to retrieve that data. The extraction will be an SQL piece of code which you can make fancy by letting the user choose the 3 dates he wants to query on (or you can hardcode it).

Finally, you need to format the output, csv file format requires no work, but if the user wants to look at the results on screen you’ll need to have a viewer with your field to be nicely formatted. I usually don’t recommend to format the excel file via the viewer as dates come back sometimes not as wanted, or fields formatting might require extra work.

And that’s it you’ve got a datamart with your 3 dates. The first time you will do it, you will get it wrong and it will take some time but once you start getting the hang of it, it becomes much much smoother.

3. Simulation

And yes there is another option: simulation. Simulation is a live report showing live position, cash flow, PL, etc… In simulation, build a viewer to show your PL with as much breakdown as you would like.

You can then define a dynamic table based on that simulation view. Create a feeder and batch of feeder on top. Then compute the PL data as of the 2 days in the past you need. Simulation will always compute PL as of today.

Then back in your simulation view, you can add more of the same PL fields and right click on them, output settings and select stored data. You can then choose to retrieve the data from your datamart directly in simulation and display either the datamart number or the variation with the current data. You can also choose to retrieve based on a shifter (like the day before, 1 month before, first day of the month, etc…) and you can do it as many times as you like (and as you have data of course!).

In a nutshell, that’s how you can solve your problem of a report showing PL as of 3 dates. I am sure you will have tons more questions, feel free to experiment, check your environment for already existing examples and ask here if you’re stuck!

Murex performance – is the system slow?

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.

Debugging crashes

Alright, this post will be very much focused on how to debug issues and will be low level.

Murex does crash and number of times, working for Murex we did not get all the information we needed to pinpoint precisely the problem.

The system crashes… what to do?

The first thing is to gather information from the user encountering the crash and understand what was the user doing, if it happened regularly, etc… One important thing to check, if the crash is recent: was anything changed recently (change of configuration or setting for example).

The second step is to reproduce the crash on your side (hopefully without the user). If the crash is too random or cannot be reproduced at will, the best is then to gather the core files and share them with Murex to obtain more information as to what the session was doing at the time.

Assuming the crash can be reproduced, the next step is to narrow it down. This step will actually speed greatly the turnaround from Murex side on the problem. And it might also lead to a workaround to the crash. Depending as to where the crash is happening, there could be multiple way of proceeding. I’ll cover the most common case: crash happening while loading multiple transactions.

If you’re lucky, the transaction scan watching might give you the answer. Transaction scan watching basically logs in when a transaction is opened for valuation and then logs it out. So each transaction should appear an even number of times. If one does appear an odd amount of time (and it’s the last one on the list) you might then have a winner. To confirm that the transaction is indeed the culprit, just try your process (accounting entries generation, simulation) on that single trade and see if the crash occurs.

To use transaction scan watching, go to help-monitor, SPB Information and choose transaction scan watching (Zap). This will delete the existing log (transaction scan watching is only used for debugging, you do not endanger anything by zapping it out, except of course if someone else is doing debugging at the same time!). Then choose activate and run your process again. Once it crashes, with a new session choose Transaction scan watching (Display) to check the log.

If the transaction scan watching fails to focus on a single trade, it will give you trades which have already been processed and might also give you a trend: all IRS have passed, it failed while doing loans. Be careful with this info as the way of scanning transactions is not always clear.
Without the transaction scan watching, to narrow it down, you then need to break it down by portfolios or deal type (usually the knowledge of what was changed recently helps as you can focus on what you suspect being wrong first). Don’t hesitate to use filters on trades inserted today or which had events performed on them during the day.

Once you have the trade, check it out (check also the static data and market data it uses) to understand where is the issue coming from. If you can fix it, it’s a win .
If you can’t, you can then test that the issue occurs with a new trade for which you picked the same pattern. And in that case, congrats you’ve found the bug and can raise it as such.