question

Upvotes
Accepted
1 0 0 1

2 RICs 510500.SS/SSd is showing different values in raw data as per client, the value of FID 1352 on 510500.SSd has correct encoding for Chinese character but Level 1 RIC 510500.SS doesn’t.

510500.SS (level 1)

<0x1B>$*5<0x1B>}<0xC4><0xE3><0xF8><0xFD>500ETF

510500.SSd (level 2)

<0x1B>%0<0xE4><0xB8><0xAD><0xE8><0xAD><0x89>500ETF

Raising in behalf of client, Yong Liu from Morgan Stanley. Client is an Elektron Real time feed client.

elektron#technologyapi#contentencodingnda-raw
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
85.9k 292 53 78

@irving.deauna

Thanks for reaching out to us.

It uses different encodings. 510500.SSd uses the UTF8 encoding while 510500.SS may use the RMTES encoding.

However, APIs can convert those raw data to the same UTF8 string.

<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REFRESH domainType="MARKET_PRICE" streamId="5" containerType="FIELD_LIST" flags="0x1FA (HAS_PERM_DATA|HAS_MSG_KEY|HAS_SEQ_NUM|SOLICITED|REFRESH_COMPLETE|HAS_QOS|CLEAR_CACHE)" groupId="1" seqNum="27072" permData="0301 0168 53C0" Qos: Realtime/JustInTimeConflated/Static - timeInfo: 0 - rateInfo: 0 State: Open/Ok/None - text: "" dataSize="26">
    <key flags="0x07 (HAS_SERVICE_ID|HAS_NAME|HAS_NAME_TYPE)" serviceId="10000" name="510500.SS" nameType="1"/>
    <dataBody>
        <fieldList flags="0x09 (HAS_FIELD_LIST_INFO|HAS_STANDARD_DATA)" fieldListNum="0" dictionaryId="1">
            <fieldEntry fieldId="1352" data="1B24 2A35 1B7D C4E3 F8FD 3530 3045 5446"/>
        </fieldList>
    </dataBody>
</REFRESH>

Item Name: 510500.SS
Service Name: ELEKTRON_DD
Item State: Open / Ok / None / ''
Fid: 1352 Name = DSPLY_NMLL DataType: Rmtes Value: 中證500ETF


<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REFRESH domainType="MARKET_PRICE" streamId="5" containerType="FIELD_LIST" flags="0x1FA (HAS_PERM_DATA|HAS_MSG_KEY|HAS_SEQ_NUM|SOLICITED|REFRESH_COMPLETE|HAS_QOS|CLEAR_CACHE)" groupId="2" seqNum="44959" permData="0301 0168 53C0" Qos: Realtime/JustInTimeConflated/Static - timeInfo: 0 - rateInfo: 0 State: Open/Ok/None - text: "****Request Completed" dataSize="25">
    <key flags="0x07 (HAS_SERVICE_ID|HAS_NAME|HAS_NAME_TYPE)" serviceId="10000" name="510500.SSd" nameType="1"/>
    <dataBody>
        <fieldList flags="0x09 (HAS_FIELD_LIST_INFO|HAS_STANDARD_DATA)" fieldListNum="0" dictionaryId="1">
            <fieldEntry fieldId="1352" data="1B25 30E4 B8AD E8AD 8935 3030 4554 46"/>
        </fieldList>
    </dataBody>
</REFRESH>


Item Name: 510500.SSd
Service Name: ELEKTRON_DD
Item State: Open / Ok / None / '****Request Completed'
Fid: 1352 Name = DSPLY_NMLL DataType: Rmtes Value: 中證500ETF

I hope this will help.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 0 0

Hi Jirapongse,

Thank you for the response. User is using PuTTy that got below result.

510500 ss| grep lldn

193 lldn ▒▒▒▒500ETF

510500 ssD| grep lldn

53 lldn 中證500ETF

(here lldn=FID 1352)

Checked the setting on puTTy and iso 2022 and CNS 11643-1986 are not on the support list.

A question: Why Level 1 and level 2 data using different encoding?

Thank you

Yong



icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
85.9k 292 53 78

@yong.liu

The RWF type of this field DSPLY_NMLL (1352) is RMTES.

DSPLY_NMLL "LCL LANG DSP NM"     1352  NULL        ALPHANUMERIC       32  RMTES_STRING    32

The client should not use the raw encoded data directly. The data must use our libraries (EMA or ETA) to decode the data. From my test, our EMA library can decode those raw encoded data to 中證500ETF.


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.