Using your own message-id on a get with correlation-id continued

[John J. Leonard]

My thanks to all who replied. I now understand that our work around is the
only way to make this work. I was puzzled when I was informed The MQMD-
MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I
look at the COBOL copybooks both fields are just PIC X 24. Never the less
when I read MQBYTE data type is treated as a string of bits, and not as a
binary number or character than my understanding increased and I realized our
work around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I
apologize.
I generate a message-id in character and use it to put message1 on the
queue. That message-id is than placed in the body of a second message
which is then put on queue. That second message contains other data
elements in the body in addition to the message-id. The distributed application
reads the second message then uses the message-id in the body to read the
first message.
If I use the MQ generated message id instead of my character message-id
when the second message is read and converted the MQ generated message-
id within the body would be junk. That is why we have a character message
id instead of the MQ generated message-id.
Our work around is for the distributed application to take the ‘1234’ and make
it x’F1F2F3F4’ and use that to read the first message doing a get by message-
id.
Again my thanks to all of you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Tim Zielke]

Maybe one option is to take that application generated message-id from the first PUT and set the CORELID of the second message to that message-id when you do the PUT of the second message? Then when you get the second message, you can just use the CORELID from that second message to get the first message with that CORELID? You wouldn't have to play around with adjusting it that way.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of John J. Leonard
Sent: Tuesday, March 18, 2014 12:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Using your own message-id on a get with correlation-id continued

My thanks to all who replied. I now understand that our work around is the only way to make this work. I was puzzled when I was informed The MQMD- MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I look at the COBOL copybooks both fields are just PIC X 24. Never the less when I read MQBYTE data type is treated as a string of bits, and not as a binary number or character than my understanding increased and I realized our work around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I apologize.
I generate a message-id in character and use it to put message1 on the queue. That message-id is than placed in the body of a second message which is then put on queue. That second message contains other data elements in the body in addition to the message-id. The distributed application reads the second message then uses the message-id in the body to read the first message.
If I use the MQ generated message id instead of my character message-id when the second message is read and converted the MQ generated message- id within the body would be junk. That is why we have a character message id instead of the MQ generated message-id.
Our work around is for the distributed application to take the '1234' and make it x'F1F2F3F4' and use that to read the first message doing a get by message- id.
Again my thanks to all of you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[David Awerbuch (BLOOMBERG/ 120 PARK)]

Tim,

You took the words right out of my mouth - that is exactly what I was going to write to John when your response came in.

This is the best way to meet john's requirements
- 100% WMQ fields
- no worry about data conversion
- no need to 'correct' the data to make the platforms match each other
- and no worry about character-set issues when using alphabetics and not just numerics.

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Mar 18 2014 14:02:57

Maybe one option is to take that application generated message-id from the first PUT and set the CORELID of the second message to that message-id when you do the PUT of the second message? Then when you get the second message, you can just use the CORELID from that second message to get the first message with that CORELID? You wouldn't have to play around with adjusting it that way.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of John J. Leonard
Sent: Tuesday, March 18, 2014 12:39 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Using your own message-id on a get with correlation-id continued

My thanks to all who replied. I now understand that our work around is the only way to make this work. I was puzzled when I was informed The MQMD- MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I look at the COBOL copybooks both fields are just PIC X 24. Never the less when I read MQBYTE data type is treated as a string of bits, and not as a binary number or character than my understanding increased and I realized our work around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I apologize.
I generate a message-id in character and use it to put message1 on the queue. That message-id is than placed in the body of a second message which is then put on queue. That second message contains other data elements in the body in addition to the message-id. The distributed application reads the second message then uses the message-id in the body to read the first message.
If I use the MQ generated message id instead of my character message-id when the second message is read and converted the MQ generated message- id within the body would be junk. That is why we have a character message id instead of the MQ generated message-id.
Our work around is for the distributed application to take the '1234' and make it x'F1F2F3F4' and use that to read the first message doing a get by message- id.
Again my thanks to all of you.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



<< "Once the game is over, the king and the pawn go back into the same box." - Anon >>

[John J. Leonard]

For Dave & Tim;

I left it out for brevity but in the reply I recieve from Tom D . it said "The
MQMD-MSGID and MQMD-CORRELID and both defined as MQBYTE24. Fields
defined as MQBYTE do not participate in normal data conversion. The
distributed application would have to process the MQMD-CORRELID as the
EBCDIC data equivalent and not the ASCII form."

Based upon that I have to think using the correlation-id would suffer from the
same issue.

Again thanks for the replies Tom taught the MQ class I took years ago so if he
says this is how it has to be done I believe him. BTW dob't know if he still
does the class but it was well worth it.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Roger Lacroix]

Hi John,

> The distributed application would have to process the
MQMD-CORRELID as the EBCDIC data equivalent and not the ASCII form."

Misconception. There is nothing for the distributed application to process.

If it is a C application then the code to save the MsgId is:

memcpy(savedMsgId, md.MsgId, MQ_MSG_ID_LENGTH);

Or Java it would be:

byte[] saveMsgId = receiveMsg.messageId;

An application, mainframe or distributed, should never ever "process"
a MsgId or CorrelId. The code should use it "as is". Now if you
want to print it out, then you treat it as a hex data and print it
out in hexadecimal dump.

Regards,
Roger Lacroix
Capitalware Inc.

At 02:32 PM 3/18/2014, you wrote:
>For Dave & Tim;
>
>I left it out for brevity but in the reply I recieve from Tom D . it
>said "The
>MQMD-MSGID and MQMD-CORRELID and both defined as MQBYTE24. Fields
>defined as MQBYTE do not participate in normal data conversion. The
>distributed application would have to process the MQMD-CORRELID as the
>EBCDIC data equivalent and not the ASCII form."
>
>Based upon that I have to think using the correlation-id would
>suffer from the
>same issue.
>
>Again thanks for the replies Tom taught the MQ class I took years
>ago so if he
>says this is how it has to be done I believe him. BTW dob't know if he still
>does the class but it was well worth it.
>
>To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
>in the message body (not the subject), write: SIGNOFF MQSERIES
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Roger Lacroix]

Hi John,

> For Roger L. Obviously I did not express the issue very well; for
that I apologize.

No. I got it the first time. I've been doing consulting work long
enough that I have seen this before and scratched my head about it.

Your architect has created a designed that is overly complex for no
valid reason. Mainframe application sends 2 messages with your
character string in different places. The distributed application
reads the messages in reverse order to handle your character string
and sends a reply message with your character string in the CorrelId
field. Way, way too complex.

Tim and David's latest responses are the way to go.

Of course, why not take a step back. MQMD's CorrelId field's real
name is correlation identification. Your goal is to correlate 3
messages right? (2 mainframe puts and 1 distributed put)

Since you are hooked on your character string (i.e.
'123456789012345678901234') then put it in the Correlld field of all
3 messages and do not put it in the message body of message # 2. Now
you have correlated all related messages into 1 group. It is easy to
understand and it is easy to implement.

Regards,
Roger Lacroix
Capitalware Inc.

At 01:38 PM 3/18/2014, you wrote:
>My thanks to all who replied. I now understand that our work around is the
>only way to make this work. I was puzzled when I was informed The MQMD-
>MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I
>look at the COBOL copybooks both fields are just PIC X 24. Never the less
>when I read MQBYTE data type is treated as a string of bits, and not as a
>binary number or character than my understanding increased and I realized our
>work around is what needs to be done.
>For Roger L. Obviously I did not express the issue very well; for that I
>apologize.
>I generate a message-id in character and use it to put message1 on the
>queue. That message-id is than placed in the body of a second message
>which is then put on queue. That second message contains other data
>elements in the body in addition to the message-id. The distributed
>application
>reads the second message then uses the message-id in the body to read the
>first message.
> If I use the MQ generated message id instead of my character message-id
>when the second message is read and converted the MQ generated message-
>id within the body would be junk. That is why we have a character message
>id instead of the MQ generated message-id.
>Our work around is for the distributed application to take the
>'1234' and make
>it x'F1F2F3F4' and use that to read the first message doing a get by message-
>id.
>Again my thanks to all of you.
>
>To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
>in the message body (not the subject), write: SIGNOFF MQSERIES
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Give it a try. It will work. :-).

Tom's comment was more around what you would have to do if you take the data from the message body after MQ has converted it from EBCDIC to ASCII. The CORELID will not be converted by MQ, so you will be able to just use it as is.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of John J. Leonard
Sent: Tuesday, March 18, 2014 1:33 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Using your own message-id on a get with correlation-id continued

For Dave & Tim;

I left it out for brevity but in the reply I recieve from Tom D . it said "The MQMD-MSGID and MQMD-CORRELID and both defined as MQBYTE24. Fields defined as MQBYTE do not participate in normal data conversion. The distributed application would have to process the MQMD-CORRELID as the EBCDIC data equivalent and not the ASCII form."

Based upon that I have to think using the correlation-id would suffer from the same issue.

Again thanks for the replies Tom taught the MQ class I took years ago so if he says this is how it has to be done I believe him. BTW dob't know if he still does the class but it was well worth it.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Ward, Mike S]

You missed Rogers point. His is the correct way to do it.

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of John J. Leonard
Sent: Tuesday, March 18, 2014 12:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Using your own message-id on a get with correlation-id continued

My thanks to all who replied. I now understand that our work around is the only way to make this work. I was puzzled when I was informed The MQMD- MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I look at the COBOL copybooks both fields are just PIC X 24. Never the less when I read MQBYTE data type is treated as a string of bits, and not as a binary number or character than my understanding increased and I realized our work around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I apologize.
I generate a message-id in character and use it to put message1 on the queue. That message-id is than placed in the body of a second message which is then put on queue. That second message contains other data elements in the body in addition to the message-id. The distributed application reads the second message then uses the message-id in the body to read the first message.
If I use the MQ generated message id instead of my character message-id when the second message is read and converted the MQ generated message- id within the body would be junk. That is why we have a character message id instead of the MQ generated message-id.
Our work around is for the distributed application to take the '1234' and make it x'F1F2F3F4' and use that to read the first message doing a get by message- id.
Again my thanks to all of you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

==========================
This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Michael Dag]

Why not use Message Properties for this!?

They were created so you could attach your own whatever to a message and use
it for whatever purpose and
not pollute/misuse MQMD fields or pollute/attach data to your message data
itself...

Michael
www.mqsystems.com

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Ward, Mike S
Sent: dinsdag 18 maart 2014 21:43
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using your own message-id on a get with correlation-id
continued

You missed Rogers point. His is the correct way to do it.

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
John J. Leonard
Sent: Tuesday, March 18, 2014 12:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Using your own message-id on a get with correlation-id continued

My thanks to all who replied. I now understand that our work around is the
only way to make this work. I was puzzled when I was informed The MQMD-
MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I look at
the COBOL copybooks both fields are just PIC X 24. Never the less when I
read MQBYTE data type is treated as a string of bits, and not as a binary
number or character than my understanding increased and I realized our work
around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I
apologize.
I generate a message-id in character and use it to put message1 on the
queue. That message-id is than placed in the body of a second message which
is then put on queue. That second message contains other data elements in
the body in addition to the message-id. The distributed application reads
the second message then uses the message-id in the body to read the first
message.
If I use the MQ generated message id instead of my character message-id
when the second message is read and converted the MQ generated message- id
within the body would be junk. That is why we have a character message id
instead of the MQ generated message-id.
Our work around is for the distributed application to take the '1234' and
make it x'F1F2F3F4' and use that to read the first message doing a get by
message- id.
Again my thanks to all of you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

==========================
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to which it is addressed. If
you have received this email in error, please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this message by mistake and
delete this e-mail from your system. If you are not the intended recipient,
you are notified that disclosing, copying, distributing or taking any action
in reliance on the contents of this information is strictly prohibited.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Ian Alderson]

Michael,
I was going to suggest the same. But I think the OP just wants to correlate messages and is only hitting a problem because of how the MsgID and CorrelID are being used/misused.

My own take on it is if you just need to correlate messages, then copying the QMgr generated messageID to CorrelID and getting on CorrelID works as designed regardless of platform. The old fashioned way of you like. Added to that you can index a queue on CorrelID (at least on z - I'm not convinced of the performance of "dynamic" indexing on distributed for a deep queue).
If however you want to "process" the correlation identifier in any manner, or somehow have a need for it to be user readable, then yes user message properties were designed for exactly that reason. Examples may be using an account ref, a sequence number or some text based tag etc. I've seen some ugly implementations of CorrelID when set by applications across z and distributed when message properties would have worked much better.

Cheers,
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



-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Michael Dag
Sent: Wednesday, March 19, 2014 10:50 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Using your own message-id on a get with correlation-id continued

Why not use Message Properties for this!?

They were created so you could attach your own whatever to a message and use it for whatever purpose and not pollute/misuse MQMD fields or pollute/attach data to your message data itself...

Michael
www.mqsystems.com

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Ward, Mike S
Sent: dinsdag 18 maart 2014 21:43
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Using your own message-id on a get with correlation-id continued

You missed Rogers point. His is the correct way to do it.

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of John J. Leonard
Sent: Tuesday, March 18, 2014 12:39 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Using your own message-id on a get with correlation-id continued

My thanks to all who replied. I now understand that our work around is the only way to make this work. I was puzzled when I was informed The MQMD- MSGID and MQMD-CORRELID and both defined as MQBYTE24 cause when I look at the COBOL copybooks both fields are just PIC X 24. Never the less when I read MQBYTE data type is treated as a string of bits, and not as a binary number or character than my understanding increased and I realized our work around is what needs to be done.
For Roger L. Obviously I did not express the issue very well; for that I apologize.
I generate a message-id in character and use it to put message1 on the queue. That message-id is than placed in the body of a second message which is then put on queue. That second message contains other data elements in the body in addition to the message-id. The distributed application reads the second message then uses the message-id in the body to read the first message.
If I use the MQ generated message id instead of my character message-id when the second message is read and converted the MQ generated message- id within the body would be junk. That is why we have a character message id instead of the MQ generated message-id.
Our work around is for the distributed application to take the '1234' and make it x'F1F2F3F4' and use that to read the first message doing a get by
message- id.
Again my thanks to all of you.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

==========================
This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
**************************************************************

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: [phone] 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: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

***************************