When a 'java' thread calls into the MQ JNI then any locks taken within
that JNI call will be released before the JNI call completes.
A 'native' thread using MQ code in a process with a JVM loaded will never
invoke code in the JVM while owning an inter process lock (or any
intra-process lock which could be requested by the owner of an
inter-process lock).
From what I've seen in this discussion I think we're safe at the MQ system
level. At an application level it seems you have to worry about the JVM
freezing while GC takes place (for example a message could be locked to an
application thread in a JVM), but I guess java programmers must be used to
that.
From: Ian Alderson <***@IGNISASSET.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 22/01/2014 09:55
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse
a get inhibited queue
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Tim,
Thank you so much for posting the follow-up from the PMR.
Andy,
I take it from your response that there seems to be no risk of the GC
locking any MQ IPC resources when using standard bindings mode. Which is
good news!
But at the risk of flogging a dead horse, can I just clarify your
statement about no MQ locks being made in java and how that applies to
calls made using the the JNI native interface (i.e. done through the .so
file when using bindings mode)? I only ask because the response in the
PMR states
âNative threads are not suspended unless they need VM access, in which
case they block at that point.â
Iâm sure youâve considered that in your answer, but as weâve come this far
into diving deep into the GC, Iâd just like to remove that last tiny doubt
in my mind.
Thanks,
Ian
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Tuesday, January 21, 2014 4:20 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
From an MQ internal perspective, no inter process MQ internal locks would
ever be held while executing in java, and hence no inter process MQ
internal locks could be held when a safepoint was reached, and hence no
internal MQ inter process locks can be affected by the gc.
Similarly, no internal MQ intra process native locks would ever be held
while executing in java, and the same argument also applies to these
locks.
From: Tim Zielke <***@AON.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 21/01/2014 15:46
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse
a get inhibited queue
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
FYI, here was some information from my follow up service request. My take
is that there is not much safe guarding from the IBM Linux JVM stand point
during stop-the-world GC to prevent a Java thread that was holding an MQ
inter-process lock from being "frozen" or stopped.
From IBM:
First of all, the Linux and Solaris implementations of GC are
completely different as the Linux version of Java is developed by IBM,
whereas the Solaris version comes from Oracle. Let me discuss the
Linux (IBM) implementation.
There are a number of GC policies which can be used in Java. In
Java 6 there are
optthruput - which aims to give the best throughput,
optavgpause - which sacrifices some performance to minimise GC
pause times
gencon - which aims to improve GC performance by concentrating
on young objects
The default for Java6 is optavgpause, but later versions use gencon
as it has proved to be benficial to many customers.
All the policies have some element of stop-the-world in them.
optthruput does all its work in this mode, while optavgpause does
a lot of work concurrently with Java work and then has a final
stop-the-world phase.
Thread suspension is done co-operatively. Java threads reach a safe
point and then suspend themselves. Native threads are not suspended
unless they need VM access, in which case they block at that point.
The performance of GC can be monitored by adding -verbose:gc to
the Java options. The GCMV plugin to IBM Support Assistant enables
the output to be visualised in a variety of ways including highlighting
the pause times.
See http://www.ibm.com/developerworks/java/jdk/tools/gcmv/ for more
details.
The details of the Solaris GC and the available policies are different,
but I believe that fundamentals are the same.
Please see the memory Management section of the Java Diagnostics guide
at http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp for
more information about the IBM garbage collector.
My follow up question:
I did have one follow up on this comment:
"Thread suspension is done co-operatively. Java threads reach a
safe point and then suspend themselves. Native threads are not suspended
unless they need VM access, in which case they block at that point."
When the java thread decides that a safe point has been reached, is it
taking into consideration in this safe point process if the thread
might be holding any locks? For example, if the java thread was
holding an inter-process lock that other processes on the server were
waiting on, this would cause a delay in the other processes until this
java thread is continued and is able to release the lock. So is the
safe point processing taking into consideration if any locks (i.e.
semaphores, mutexes, etc.) are being held by that the java thread
before it is suspended?
IBM respnonse:
The JVM only concerns itself with its own locks and not with any
non-Java locks such as semaphores or mutexes.
Thanks,
Tim
From: Tim Zielke
Sent: Thursday, January 16, 2014 8:27 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: RE: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Hi Ian,
I agree with your assessment, as well. However, we have some MQ server
side Java apps that are involved in performance SLAs. Switching to
MQCNO_ISOLATED_BINDING should be negligible on the SLA, since the isolated
binding performance is generally between shared and client bindings, per
Andy. Assuming (and this definitely an assumption at this point) that
there is the remote risk for significant queue manager slow downs due to a
long running JVM stop-the-world garbage collection stopping a thread that
is holding an inter-process MQ lock, it actually makes some sense for us
to consider switching to MQCNO_ISOLATED_BINDING for our server side Java
applications that use MQ. Anyway, I plan on following up with an IBM
service request to hopefully get a more definitive answer on this topic.
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Ian Alderson
Sent: Thursday, January 16, 2014 3:44 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Tim and Andy, thanks for the extra information. Iâm not overly concerned
about this potential issue but itâs certainly something to be aware of and
would be good to get a deeper understanding. From reading the responses
it would seem to me that the window of for GC to freeze a part of the qmgr
is (probably) small. But I could imagine you could increase the odds by
having an application running lots of threads and/or continually creating
lots of connections where the lock has a much larger scope (of course
creating a lot of unnecessary connections is generally regarding as bad
practice).
Andy,
If the qmgr cannot obtain a lock, would this generally be recorded in the
MQ error logs? I recall being advised by L3 support to set isolated
bindings once for an app running on WAS 6 and MQ 6 a few years ago, but I
canât remember the detail of the why, but I think it could have been
related to AIXâs EXTSHM â however I digressâŠ
I agree it would be good to have a JVM internals expert give their view,
especially if they can relate it to the MQ classes (JMS and base).
I revisited a link I had about JMS versus base java classes running in a
J2EE environment.
https://www-304.ibm.com/support/docview.wss?uid=swg21266535
Using base MQ java classes in a J2EE container is not recommended, and
although I would hope most code is now using JMS I am sure there will
still be some apps out there. The section on Thread Creation (and
cleanup) looks interesting as it might relate to how GC treats the MQ
threads.
Of course there will be lots of standalone java apps running the MQ base
classes legitimately, although I see more developers using JMS as standard
for these implementations these days, so would be interesting to know if
the potential for locking is inherently different when using either set of
classes.
Thanks,
Ian
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Tuesday, January 14, 2014 10:58 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
I did find this article that provides a little more information on the
topic -> http://www.infoq.com/articles/Java_Garbage_Collection_Distilled
Relevant Section:
"To bring an application to a total stop it is necessary to pause all the
running threads. Garbage collectors do this by signaling the threads to
stop when they come to a âsafepointâ, which is a point during program
execution at which all GC roots are known and all heap object contents are
consistent. Depending on what a thread is doing it may take some time to
reach a safepoint. Safepoint checks are normally performed on method
returns and loop back edges, but can be optimized away in some places
making them more dynamically rare. For example, if a thread is copying a
large array, cloning a large object, or executing a monotonic counted loop
with a finite bound, it may be many milliseconds before a safepoint is
reached."
If there is a JVM internals expert out there (or someone knows one at IBM?
:-) ), it would be great to hear what they say on the matter.
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Tuesday, January 14, 2014 6:49 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: MQ locks and JVM stop-the-world
There's an assertion here that Java garbage collection is blindly sending
SIGSTOP to threads in the same process regardless of their current state.
The article referenced by Tim doesn't go as far as to state this, and it's
well beyond my Java knowledge. All pre-emptive dispatching involves
potentially losing control for short periods of time while holding locks,
but the suggestion here is that threads could randomly be frozen for
prolonged periods of time, and in this environment then any hope of
meeting reasonable SLA's would seem improbable. We could really do with a
knowledgeable JVM internals expert chipping in at this time and explaining
the JVM implementation and strategy.
Pretty much all standard bound MQI calls involve taking at least one inter
process lock at some point, but the scope and granularity of the locks
varies massively, for example during a standard bound MQCONN a coarse lock
is obtained, which would inhibit all other standard bound MQCONN activity.
Conversely, inter process locks used in the application process during
MQPUT/MQGET are held for very few instructions and have a much smaller
scope.
Isolated bindings are independent of MQ client bindings, and do not use
amqrmppa processes. Isolated bindings use unix domain sockets and a thread
in an amqzlas0 process will exist in much the same way that a thread in an
amqzlaa0 process exists on behalf of a standard bound application. The
performance of isolated bindings is generally someplace between shared
binding and client bindings.
From: Ian Alderson <***@IGNISASSET.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 14/01/2014 09:53
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse
a get inhibited queue
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Andy,
That is a very interesting (and may I say slightly alarming) point about
JVM GC potentially freezing some part of a QMgr. There must be a lot of
JVMs out there that are connected using server bindings, and if this is a
potential issue then the window must be very very small or the effect so
slight that it is mostly not noticed. Having said that, the most common
implementation I have seen when an app server like WAS is co-located with
a qmgr is that the apps in WAS still connect using MQClient (with the
added benefit that HA failover of the QMgr is then independent of a WAS
cluster).
So just to make sure I understand the risk. If a JVM is connected to MQ
using bindings mode, then during GC when it will send STOP signals to all
its threads, a lock on one or more IPC resources could prevent another
part of the qmgr from gaining said lock? What is the window for this
lock, on a connect of pretty much any MQ operation?
Also
âUsing ISOLATED MQ bindings (MQCNO_ISOLATED_BINDING) would eliminate this
risk at the expense of some performanceâ
I believe using ISOLATED bindings will effectively force the application
to stop using the shared IPC resources. In terms of performance, is it
fair to say that performance would be comparable to running a client
bindings on the same server (using the loopback address)? At this point I
am not clear if isolated bindings would use amqrmppa or some other process
in the absence of IPC. If my understanding is off the mark please do let
me know.
Thanks,
Ian
Ian Alderson
MQ Technical Architect
DL 0203 003 3055
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET
http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Monday, January 13, 2014 4:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Thanks, Andy!
To the other MQ administrators on this LISTSERV that support server side
java applications (like we do), below is a link to more information about
this Java garbage collection topic (in Java garbage collection terminology
it is called stop-the-world), in case you are interested. I would think
it would be helpful to at least be aware of its existence, and potential
(although probably remote?) impact to MQ queue manager performance.
http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/
Here is a relevant snippet from the above link:
"Returning back to Garbage Collection, there is a term that you should
know before learning about GC. The term is "stop-the-world."
Stop-the-world will occur no matter which GC algorithm you choose.
Stop-the-world means that the JVM is stopping the application from running
to execute a GC. When stop-the-world occurs, every thread except for the
threads needed for the GC will stop their tasks. The interrupted tasks
will resume only after the GC task has completed. GC tuning often means
reducing this stop-the-world time."
I did also run across a Java technology from Azul that says it does not
use any stop-the-world algorithms in its garbage collection, but it does
not look like this JVM is supported for WebSphere MQ according to the
manual.
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Monday, January 13, 2014 2:19 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Thread on STOP signals and MQ
If the JVM is simply sending STOP signals to threads without understanding
the context of those threads then it risks sending a STOP signal to an MQ
related thread while that thread holds an MQ lock, and thus freezing some
queue manager capabilities until the thread is resumed. Using ISOLATED MQ
bindings (MQCNO_ISOLATED_BINDING) would eliminate this risk at the expense
of some performance.
From: Tim Zielke <***@AON.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 13/01/2014 03:12
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse
a get inhibited queue
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Hi Andy,
I had a follow up on this comment:
"Sending a STOP signal to an MQ server side application is dangerous
enough"
My understanding is that when a JVM needs to run certain types of garbage
collection, the applicable JVM system thread sends a STOP signal to all
the application threads in order for the garbage collection to take place.
So it is possible if you have a long garbage collection scavenger run
that lasted 15 seconds in your JVM, all the application threads for that
JVM would receive a STOP signal and would subsequently be stopped for that
15 seconds. Does this mean that an MQ queue manager is somewhat
susceptible to what you are describing below if a server side java
application was connected to the queue manager, since my understanding is
JVMs are constantly sending STOP signals to their application threads?
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Thursday, December 12, 2013 2:38 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Sending a STOP signal to an MQ server side application is dangerous
enough, but sending a STOP signal to an MQ process (e.g amqrmppa) would be
extremely dangerous. If that process happened to own an inter process lock
at the time the STOP signal arrived the entire queue manager could easily
grind to a halt. The same issue does arise for a 'simple' server side
application (for example queue manager scope locks are obtained/released
during MQCONN processing), but the scope for inadvertently stopping the
queue manager is much greater with an MQ internal process.
Since MQ V7 much more specific traces have been possible, and tracing the
API calls for specific connections would seem like a much better way to
identify the cause of issues such as this.
From: Tim Zielke <***@AON.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 11/12/2013 21:27
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse
a get inhibited queue
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Yes, sending the STOP signal to a process will STOP all the threads for
that process.
This is what I would do for your case. My understanding now is you have
an isolated queue manager on its own server with MQ Client apps coming in
from different servers to PUT and GET messages to this queue manager. If
so, I would do the following:
GET disable the queue you wanted to browse
Let the message flow into the queue manager and get placed on that queue
Send a STOP signal to all of the channel processes (i.e. amqrmppa) for
that queue manager
GET enable the queue and browse the message
Send a CONT signal to all of the channel processes (i.e. amqrmppa) for
that queue manager
In my opinion, this type of activity would only be appropriate in a
Development lifecycle, like yours. But it shouldn't negatively impact the
queue manager besides temporarily stalling the channel activity, in my
opinion.
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, December 11, 2013 2:57 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Thatâs slick, butâŠ.We are primarily MQ Clients for our applications. In
the case of MQ Client, if you freeze the PID that represents the app
consuming from the queue, I imagine you are actually freezing the PID of
amqrmppa, and thus all of the up to 64 threads (channels) in that amqrmppa
would âhangâ until the PID was continued?
Nevertheless your email is getting saved and Iâm gonna play around with
that in the Lab. Might be real handy for other use cases.
Peter Potkay
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Wednesday, December 11, 2013 2:36 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Hi Peter,
If these applications run on Unix/Linux, here is one other trick that you
might want to consider for your use case for future reference since this
is a Development environment. Use the STOP signal.
There are two signals that no process can block on Unix/Linux. The KILL
signal and the STOP signal. The STOP signal will "freeze" a process from
running any longer until you send the process a subsequent CONT or
continue singal. So basically, instead of GET inhibiting the queue, you
are run inhibiting the active application processes that can GET from the
queue. Then you should be able to browse or GET your new message from the
queue, and then send the CONT signal to the consuming applications to make
them runnable again.
Here is an example. You may be already aware of how to do this, but it
might be helpful for others to document.
Let's say DIS QSTATUS shows that pid 12345 has your queue open where you
want to browse a new message from it. Do the following:
kill -s STOP 12345 (this assumes you have the appropriate access to send a
signal to this process. You may need a Unix/Linux admin to help, if not)
Have the sending application send its message
Browse the message from the queue
kill -s CONT 12345
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, December 11, 2013 8:27 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Tim,
The security checking is only done on the MQOPEN call, so if the app was
in a Get with Wait loop Iâm thinking the change in security would not give
the desired results.
Peter Potkay
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Wednesday, December 11, 2013 9:04 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Hi Peter,
Just a thought. Would another option for your use case be to temporarily
change the security on the queue that the consuming message is doing a GET
on (with a subsequent REFRESH SECURITY) so that only mqm has access to the
queue (assuming the consuming message is not leveraging the mqm group for
its security)? I would think the running consuming application would pick
up the security change after the REFRESH SECURITY and then get 2035s until
the MQ Admin has browsed the message. Then you could turn the original
application security for the queue back on followed with another REFRESH
SECURITY.
Thanks,
Tim
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, December 11, 2013 7:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Request For Enhancement - Allow an MQ Admin to browse a get
inhibited queue
Link to review the RFE and vote for it
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=42656
Description:
Enhance Websphere MQ so that a suitably authorized user (member of the mqm
group) can browse a queue even if that queue is get inhibited. The ability
to browse would be enough for our use cases, but it might be beneficial to
also allow the MQ Admin to destructively get the message(s) on the Get
Inhibited queue
Use case:
Two applications in the development environment that send MQ messages to
each other are having a bad day, each laying blame on the other as to what
is actually being sent to the other. Classic he sent, she sent. Or, you're
not gonna believe this, they claim that MQ is changing the content of the
message. So we tell the consuming app to close the queue and then we tell
the sending app to produce another message but only when we tell them the
consuming app has finally managed to stop, at which point we can look at
it. Sounds simple. Often its not.
However, if the MQ Admin could Get Inhibit the queue yet still browse the
queue, we could work the issue without needing the consuming application
to stop. The MQ Admin could grab a copy of the message, enable the queue
for gets and the consuming app would not have had to change anything.
A use case for allowing the ability to destructively get a message might
be to allow an MQ Admin to step in and save the day when an app is stuck
in a tight loop on a poison message. Without getting the consuming app to
stop, the MQ Admin could get inhibit the queue, the poison message
identified and removed, and the queue get enabled.
Business justification:
By giving the MQ Administrator this ability it would allow them to speed
up problem resolution and exonerate Websphere MQ from being the source of
the issue.
Peter Potkay
Application Platform Engineering @ The Hartford
Websphere MQ, Message Broker and DataPower
(W) 860-624-1395 / (M) 860-202-1375
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
**************************************************************
The information contained in this email (including any attachments
transmitted within it) is confidential and is intended solely for the use
of the named person.
The unauthorised access, copying or re-use of the information in it by any
other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by
return email to ***@ignisasset.com.
Internet communication is not guaranteed to be timely, secure, error or
virus free. We accept no liability for any harm to systems or data, nor
for personal emails. Emails may be recalled, deleted and monitored.
Ignis Asset Management is the trading name of the Ignis Asset Management
Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801),
Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish
Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: 0141-222-8000
and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No.
971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and
Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: 020 3003 3000.
Scottish Mutual is a registered trade mark of Scottish Mutual Assurance
Limited
*Authorised and regulated by the Financial Conduct Authority.
**************************************************************
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU