消息队列--Focus　on　BI
商业智能领域&--知识、技术、平台、发展、业界...
&&&&&&&& 欢迎加入
&&&&&&&&&& BI Club-1 QQ群：2635140已满
&&&&&&&&&& BI Club-2 QQ群：
&&&&&&&&&&&&&&&&&&&&&& 一点声明
&&&& 鉴于这段时间有朋友投诉本blog上文章引用问题。现特此声明有部分文章为转帖，可能有原创和转帖漏掉备注的情况。这里若有您的原创文章并且是在未经您同意就引用并且您介意的情况，我在此表达诚挚歉意，请及时与我联系进行调整！
对于MQ的使用，主要会涉及到MQ系统本身的配置和MQ应用程序的开发两方面的工作。为了帮助大家更好地使用MQ，本文将就MQ配置和编程中的一些注意事项和技巧与大家探讨，并希望与大家分享这方面的一些最佳实践(Best Practice)。
第一部分：有关MQ对象配置的最佳实践
&&& 对于MQ系统配置，我们要规划MQ通讯网络，确定系统的拓扑结构，确定各种对象的属性和命名规则并创建所需的各种对象等，首先，我们谈一谈在系统建设之初，如何设计和定义MQ的各种对象。
1、有关队列管理器：创建队列管理器时，应考虑的因素主要有：
1） 队列管理器的日志类型以及日志文件的大小和个数，要根据用户数据量的大小、各个队列上的消息总容量，来计算日志的总容量，以免在系统运行过程中出现日志写满的情况；
2） 应该为队列管理器指定和建立死信队列；
3） 对最多打开句柄数MAXHANDS（缺省为256，如果您需要多于256个应用程序同时连接队列管理器，应增大该值），最大消息长度MAXMSGL，最多的未提交的消息个数MAXUMSGS属性（缺省为10000，如果您使用了消息分段或分组，某个大消息的分段个数超过了10000，应增大该值）的考虑；
4） 创建完队列管理器之后，应修改队列管理器的配置文件，考虑有关TCP和通道有关的参数的配置，举例如下：
&&TCP:&& KeepAlive=Yes&Channels:& AdoptNewMCA=ALL& PipeLineLength=2MaxActiveChannels=200&&&&
2、有关队列：对于队列的属性，应该考虑的因素主要有：
1） 永久性和非永久性设置：尤其要注意的是DEFPSIST属性的缺省值为No，若要保证消息的安全可靠，必须将其设置为Yes；
2） 对于本地队列和传输队列,要考虑队列的最大深度MAXDEPTH(缺省为5000，应根据实际情况计算该值)，队列中每个消息的最大字节数MAXMSGL的配置。
3、有关通道：对于通道的属性，应该考虑的因素主要有：
1） 确定通道的运行方式采用长连接的方式还是触发的方式，通常，对于需要频繁启动的通道，不适宜采用触发的方式。若采用触发方式启动通道，触发类型应为FIRST；
2） 对于发送类型的通道,要考虑通道的断开间隔（DISCINT）、短重试次数（SHORTRTY）、短重试间隔（SHORTTMR）、长重试次数（LONGRTY）、长重试间隔（LONGTMR）、批处理大小（BATCHSZ）的配置。
第二部分：有关MQ程序开发的最佳实践
通常大家在使用MQ时，一般在系统设计之初只考虑MQ的系统配置，而很少提前考虑应用程序编写的指导原则，往往是边写边想，边想边写，边写边改，使得开发效率和质量都比较低，为了使大家更快、更好地开发出MQ应用程序，在该部分我们给出与MQ程序开发相关的一些最佳实践，供大家参考。这里我们无法做到面面俱到，并且由于每个用户的具体需求不同，每条原则都不能一概而论，但是从普遍意义上可以作为您的参考。
为了更好地掌握和了解MQ编程的技巧，我们首先要熟悉MQ的消息通讯模式，这将帮助你更好地理解MQ编程的最佳实践。通常，MQ有两种通讯模式，即数据报(Datagram) 方式和请求/应答(Request/Reply) 方式：其中，Datagram方式通常又被称为"Send And Forget"（发送/忽略），是最简单的通讯模式，应用程序只需在创建完消息之后，利用MQ的API将消息发送到队列中，它充分利用了MQ确保消息传输，并且传一次且仅传一次(once and once only)的优势，发送端应用程序无需关心消息何时被处理。
Request/Reply（请求/应答）方式相对复杂一些，在消息发出之后，你需要等待对方的处理结果，在这种情况下，你通常需要考虑其他一些问题，如：
等待应答的时间是多少？ 如果没有收到应答，是否再次发出请求？ 应答发出之前是否会有数据库操作或其他交易被执行？ 本次请求/应答过程的会话(session)信息是否需要被保留？
通常，我们要根据用户的需求来决定采用何种通讯模式，不同的通讯模式之下对应用程序的考虑将会有所不同，使用的MQ API的参数和选项也将不同。
为了使你的MQ应用能够更加健壮，并且具有更强的可维护性，我们要学会灵活高效地使用MQ的一些特性以及相关的API选项，从而提到应用程序的质量、灵活性、可靠性和性能。这里，我们将给出一些较典型的建议。
1. 在每一个MQ API调用之后，必须检查完成码(completion code)和原因码(reason code)，对于非零的返回码，必须进行相应的处理，必要时，最好将返回码记录错误日志，从而在应用程序出现运行故障时便于检查和处理。
在MQ中，所有的API调用都会得到其完成码和原因码，完成码有MQCC_OK、MQCC_WARNING、MQCC_FAILED等，MQCC_OK表示调用成功，当得到MQCC_WARNING、MQCC_FAILED返回码时，表示API执行不完全成功，你需要进一步检查原因码，通过不同的原因码分析失败原因。如：原因码2033代表队列已空，没有消息可取；2080代表消息的实际长度超过了你在程序代码中设置的缓冲区长度等等。
2. 对MQCONN, MQOPEN，MQCLOSE, MQDISC的使用
由于MQCONN, MQOPEN，MQCLOSE, MQDISC相对于MQGET和MQPUT来说是比较消耗资源的几个函数，在一个应用中，即使你需要对某个队列进行多次读写操作，也不要对每一次读写都调用一次MQCONN, MQOPEN，MQCLOSE, MQDISC函数，正确的做法应该是，调用一次MQCONN, MQOPEN就可以对队列进行多次读写操作，另外，一定别忘记对称地使用MQCLOSE, MQDISC函数将相关资源释放掉。
3. 读取消息时，等待时间间隔的设置
对队列的读取操作，可以有两种方式，即轮巡方式和触发方式（利用MQ的触发功能动态调起应用程序）。在采用轮巡方式读取队列时，在MQGET时，我们需要设置消息读取选项MQGMO_WAIT，同时指定等待时间间隔。不少用户将时间间隔设定为MQWI_UNLIMITED以实现轮巡的目的，这样做的弊端在于在没有消息到达时应用程序陷入无限的等待，无法接收来自外部系统的相关信号，MQCLOSE,MQDISC调用也无法被执行，因此，我们建议避免采用这种方式，推荐的做法是设置特定的等待时间间隔，然后再循环发出MQGET调用。
4. 如果在同步点控制之下使用MQGET，在所有MQGET调用之后，必须检查消息的回滚次数(Backout Count)。
如果某个消息是在同步点控制之下读取的，并且由于某种原因消息被回滚，消息描述符中(Message Descriptor)的BackoutCount字段的值将被加1，你需要判断该数值，如果它大于某个阈值，你需要使用其它手段来处理该消息。否则，在某些情况下会导致读取消息-消息被回滚-再读取消息-消息再被回滚的死循环。
例如：你使用了触发机制设定当队列中消息到达时，触发某个应用程序，该应用程序在MQ XA Resource Manager的控制之下，读取消息，并且利用其数据对数据库进行更新，假设数据库出现问题，无法成功进行数据库操作，消息将被回滚；这时，又满足了触发条件，又会触发起该应用程序，周而复始，陷入死循环。在这种情况下，你必须在程序中加入对BackoutCount的判断。
5. 当处理backout消息时，可以使用队列的BOTHRESH 和 BOQNAME属性。
如4中所言，如果某个消息是在同步点控制之下读取的，并且由于某种原因消息被回滚，消息描述符中的BackoutCount字段的值将被加1，你需要判断该数值，如果它大于某个阈值，你需要使用其它手段来处理该消息。在处理该消息的应用中，你可以将其与设定的阈值做比较，这时，阈值会被写死在程序中，为了提高其灵活性，你可以使用队列的BOTHRESH 和 BOQNAME属性。这样，你可以在例外处理中，利用MQINQ查询得到阈值的大小，如果超出，可以将消息转发到BOQNAME指定的队列中，继而对该队列进行相应的处理。这种方法大大增强了应用程序的灵活性。
6. 在使用MQOPEN, MQPUT 和 MQGET调用时，要使用FAIL_IF_ QUIESCING的选项。
MQ系统本身和使用它提供的服务的用户应用程序之间是互相独立的，必要时，我们可能要停止MQ系统，这时，我们不但希望新的应用不能连接，并且希望所有已连接的应用能够立即停止。为了使所有的应用程序能够快速得知MQ系统正在停止的信号，在上述MQ API中，必须设置FAIL_IF_ QUIESCING的选项。
如果不设置FAIL_IF_ QUIESCING的选项，当MQ系统停止时，所有应用将继续运行，这样会影响MQ系统的停止，从而导致MQ停止需要很长时间，同时可能导致我们必须手工杀掉那些没有设置该选项的应用程序。
7. 消息描述符的不同字段的使用方法
在MQ的消息描述符MQMD中包含了很多字段，这些字段大部分是一些保留字段，例如：MsgID表示消息的唯一标识，如果你不指定，MQ系统会为你自动产生一个，并保证其唯一性；PutAppType, PutAppName, PutDate, PutTime是系统自动产生的，表示哪个应用何时将消息发送到队列中；再如：GroupId, MsgSeqNumber, Offset, MsgFlags是与消息分段和消息分组相关的控制信息；除了这些系统自动产生无法更改的字段和有特殊用途的字段之外，如果您想选择某些字段为己所用，将其设定为自己应用程序中某个有意义的标识，你可以使用CorrelId和Feedback字段，但是，按照惯例，CorrelId常常被用于在请求/应答通讯模式中来表示请求消息和应答消息之间的关联；因此，我们可以灵活使用Feedback字段，利用该字段来进行一些应用程序控制。当我们接收到某个消息之后，我们可以检查Feedback字段，根据Feedback字段值进行相应的处理。
8. 消息永久性属性的确定
永久性消息保证了消息在系统和网络等故障下的安全可靠，但是同时从性能角度来讲会比非永久性消息要差，因此，要从不同的角度进行权衡和分析，然后决定消息的永久性属性。当对性能要求非常高，可靠性要求相对不高时，可以首先考虑采用非永久性消息，在消息决不允许有任何丢失，并且在丢失之后又无法重新发送时，要使用永久性消息。
9. 当指定消息的永久性和非永久性属性时，最好利用应用程序显式地指定，不要使用"defined as queue"的方法来指定。
消息的永久性和非永久性是消息本身的属性，多数情况下，只有消息的原始发出者才了解丢失消息将产生的重大影响，因此，消息的原始发出者应在应用程序中显式地指定消息的永久性，如果将其定义为依赖于队列的该属性，就会比较被动，当队列的永久性属性(DEPSIST)被意外地设为NO时，就会有丢失的风险。
10. 应用程序可以将请求消息的永久性属性为No，即对于请求消息使用非永久性消息。
一般情况下，请求消息丢失对应用系统不会产生严重的影响，如果出现请求消息丢失的情况，我们可以重新发送，因此，不必将请求消息设置为永久性消息。把请求消息设置为非永久性消息的另外一个好处是，系统不需要对非永久性消息记录日志，从而减少I/O操作，提高系统的性能。
11. 在异种操作系统平台上使用MQ传输消息时，将消息格式设置为MQFMT_STRING。
MQ的一大优势之一，是对built-in(内置的)消息格式，可以实现不同操作系统平台间、不同系统字符集之间的数据转换，如开发平台ASCII码和主机EBCDIC码之间的转换。为了实现该数据转换，MQ必须获知本身和对方MQ系统的队列管理器的CCSID和Encoding以及消息的格式。一般而言，CCSID和Encoding会被自动设置和处理，不需要应用程序关心，但是，消息的格式必须由应用程序指定，对于MQ内置支持的消息格式，MQ可以自动转换，这些消息格式由MQFMT_*来指定。鉴于应用程序数据都可以用MQFMT_STRING来表示，并且MQFMT_STRING是MQ内置支持可以转换的格式之一，你可以使用它来表示你的消息格式，同时，对于数字型消息，你需要使用atoi, itoa等函数实现数字型和字符型之间的转换。
12. 对大消息的处理
MQ支持单条消息的最大长度为100M，队列管理器、队列、通道支持的最大消息的缺省值为4M，即使如此，我们却应该根据不同的网络类型和带宽，具体地确定不同情况下单条消息的合适大小。例如：如果在拨号网络或网络带宽较窄的情况下，我们将单条消息的大小设置得太大，就会影响传输效率，在这种情况下，一定要使用MQ的分段功能将消息进行分段处理，确保每一个物理消息的大小适当，MQ会自动维护整个逻辑消息的完整性，并且可以在接收端一次性将其取出。
13. 如何使用MQ的请求/应答通讯模式来处理同步的消息处理模式。
大家知道，MQ的异步处理模式是非常强健的，同时它也支持同步的消息处理，例如MQ的client-server通讯就是一种典型的同步工作模式，对于server-server通讯，我们也可以实现同步工作模式，这里就涉及到如何巧妙地使用MQ提供的消息生命周期的功能。这时，对于请求消息和应答消息我们最好为其设置生命周期。
典型的应用案例如下：假设系统A向系统B发出请求，调用B上的某个交易，这里，我们首先要设置请求消息的生命周期，并且在消息到期时将消息丢弃，如果在消息发出之前消息过期，它就会在进入通道之前，被MQ系统丢弃；如果当消息到达目的地之后，在被对方应用程序取走之前消息过期，它也将被MQ系统丢弃。系统B上的交易便不会被调起执行。对于应答消息，我们也设置它的生命周期，与请求消息不同的是，我们设置在消息到期时将其转发到另外一个特定的队列中，这时，如果系统B上的交易执行完之后，会产生应答消息，如果由于通讯等原因，该应答消息在到达系统A时应用程序设置的Timeout时间已经超出，应用程序必然认为系统B上的交易没有被执行，也不会处理该应答消息，这样，应答消息便会过期，当它过期时，根据我们的设置，它会自动被MQ系统转发到特定队列中，我们另设专门的应用程序对此进行冲正处理。
14. 对消息类型的设置。
通常情况下，我们不要求用户一定去设置消息的类型，设置消息类型的方法是在消息描述符MQMD的MsgType字段，消息类型有datagram, request, reply, report
| &上一篇：下一篇：发表评论：文档分类：
下载前请先预览，预览内容跟原文是一样的，在线预览图片经过高度压缩，下载原文更清晰。
您的浏览器不支持进度条
淘豆网网友近日为您收集整理了关于银联返回码（精选）的文档，希望对您的工作和学习有所帮助。以下是文档介绍：银联返回码应答码联网机构在遇到下表中列举的适用条件时,应使用与该适用条件对应的应答码A.27 按序号排列的应答码表应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS00承兑或交易成功成功交易成功√√√01 查发卡方失败请持卡人与发卡银行联系发卡方原因拒绝该笔交易,只有必须要求联系发卡行的情况才使用此应答码。√√√03 无效商户失败 异常;本卡在该类商户(MCC)不允许此交易;此商户在黑名单中√√√04 没收卡呑卡、没收此卡应被吞没(ATM)此卡为无效卡(POS)发卡方确信该卡应被呑没√05身份认证失败失败持卡人认证失败1、网上交易的交易信息超期送达2、持卡人身份认证失败(如委托关系或网上类交易)3、证件信息(种类、号码等)不符4、交换中心判断安全信息与交易信息的时间差超过 24 小时5、持卡人出生日期校验不符6、助农取款业务中,受理方未上送卡片信息√√10部分金额批准成功,需提示显示部分批准金额,提示操作员在允许部分金额的交易中使用√11重要人物批准(VIP)成功此为 VIP 客户发卡方向收单行提示此为 VIP 客户√12无效的关联交易失败无效交易1、原始交易未承兑,又收到了与其关联的关联交易,例如冲正交易、撤销交易;2、应隔日发生的交易非隔日发生。3、对原始交易进行隔日撤销、冲正。4、交易没执行,却收到了关联交易的信息(例如,预授权交易未承兑,又收到了预授权完成或预授权撤销交易)√√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS13 无效金额失败无效金额理应出现有效金额的交易中,金额域填 0 或其它非法值;超转付金额累计/超现付金额累计;交易超消费比例;小费金额超限此机构无法/不可进行该币种交易;√√√14无效卡号(无此账号)失败无效卡号1、发卡方无此主账号2、在找到原始交易的情况下,关联交易主账号与原始交易主账号不匹配3、卡号校验位校验不正确4、帐户已作废或消户5、应答交易主账号与请求交易的主账号不匹配√√√15 无此发卡方失败此卡无对应发卡方根据交易请求的主账号找不到对应的发卡方√16批准更新第三磁道成功更新第三磁道保留21 卡未初始化失败该卡未初始化或睡眠卡1、该卡未激活、开卡;2、该卡初始密码未变更;3、初始密码限制的交易4、长期未使用而冻结或状态为“睡眠”的卡。√22故障怀疑,关联交易错误失败操作有误,或超出交易允许天数非正常的关联交易,如以下情况:1、执行完冲正交易之后,又收到其撤销请求交易2、当前交易已被撤销,又收到其关联交易,例如冲正、撤销等3、执行完预授权撤销交易之后,又收到预授权完成交易4、执行完预授权冲正交易之后,又收到预授权完成交易5、当执行完预授权完成易后,又收到对同一笔预授权交易的预授权完成请求6、预授权类交易(包括预授权完成和预授权撤销)的发生时间超过允许的预授权类交易天数7、超出正常缴费时间√√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS25找不到原始交易失败没有原始交易,请联系发卡方可表示如下情况:1、查找不到原始交易,匹配原始请求交易出错2、匹配原始预授权、授权交易失败3、冲正交易请求未能与原始交易相匹配4、扣费、撤消和变更委托时使用,委托关系不存在√√√30报文格式错误失败请重试可表示如下情况:1、规定应出现的报文域未在报文中出现2、交易渠道取值不在规范定义中3、域解析出错4、子域解析出错5、域检查未通过6、域中出现非法字符7、接收报文中的 bitmap 不符合规范的定义8、磁道信息出错9、理应出现交易金额的交易中没有交易金额√√√34 有***嫌疑呑卡、没收***卡,呑卡该卡有***嫌疑(包括 ARQC 校验错),ATM 呑卡、操作员没收,适应以下情况:1、CVN 错误次数超过吞卡次数限额;2、卡片已被伪冒(借方)√38超过允许的PIN 试输入失败密码错误次数超限,请与发卡方联系密码错次数超限,并已对账户进行锁定,需持卡人至发卡方办理解锁√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS40请求的功能尚不支持失败发卡方不支持的交易针对机构不支持的功能,可表示为如下情况:1、发卡机构尚未开通此交易2、虽然可以从联网机构的报文中确定出交易种类,但该交易目前未开放3、联网机构虽然可以从接收到的报文中确定出交易种类,但在接收方的权限表或特殊权限表中未包含该交易4、虽然可以从联网机构的报文中确定出交易种类,但接收方的报文版本不支持5、对于一笔 IC 卡交易,若接收方是Early 状态,而接收方却不要求校验ARQC6、发卡方无法进行某些验证要素的校验√√41 挂失卡呑卡、没收此卡已挂失,呑卡(ATM)挂失卡(POS)挂失的卡,吞没√43 被窃卡呑卡、没收此卡被没收,请与发卡方联系(ATM)被窃卡(POS)发卡方确认此卡为被窃的卡,吞没√51 资金不足失败可用余额不足账户可用余额不足,信用额度不足,取现额度超限√54 过期的卡失败该卡已过期过期卡,到期日期不正确√55 不正确的 PIN 失败密码错 PIN 验证未通过√57不允许持卡人进行的交易失败不允许此卡交易发卡方对持卡人的信用及风险状况等原因,不允许进行交易的情况,包括但不限于:1、该卡种不能做此种交易2、超服务范围3、不受理该种卡4、单位卡不能存款5、该帐户没有该币种6、此卡有套现嫌疑7、卡号或证件号在黑名单中√√√58不允许终端进行的交易失败发卡方不允许该卡在本终端进行此交易1、发卡方在限制此类终端进行相关交易(可能针对某些卡 BIN)2、关联交易中终端号与原始交易中终端号不匹配√√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS59 有***嫌疑失败卡片校验错 CVN 验证失败√√61超出金额限制失败交易金额超限交易金额超限,包括但不限于:1、超单笔消费限额/超 ATM 单笔取现限额2、ATM 日取现/POS 日消费金额超限3、超持卡人自定义单笔取款/消费4、超转帐限额√√√62 受限制的卡失败受限制的卡受限制的卡(受理服务地区限制等原因),不吞没√√64原始金额错误失败交易金额与原交易不匹配1、请求报文中的交易金额与应答报文中的交易金额不匹配(部分扣款情况除外)√√√2、关联交易报文中的交易金额与原始交易报文中的交易金额不匹配(部分扣款情况除外)65超出取款/消费次数限制失败超出取款次数限制1、超出当日取款/消费次数限制2、超转付次数累计/超现付次数累计;√68发卡行响应超时失败交易超时,请重试接收机构超时未收到发卡方应答√75允许的输入PIN 次数超限失败密码错误次数超限密码输入错误次数超限√90正在日终处理()失败系统日切,请稍后重试正在进行日期切换√√91发卡方不能操作失败发卡方状态不正常,请稍后重试用于表示由于发卡方(或转入/转出方)的错误而导致交易被拒绝,如以下情况:1、发卡方(或转入/转出方)运行不正常2、发卡方(或转入/转出方)异常,但又未和银联处理中心签定代授权协议3、发卡方(或转入/转出方)签退、未签到4、发卡方(或转入/转出方)运行状态无效5、发卡方(或转入/转出方)被银联处理中心关闭6、发卡方(或转入/转出方)线路异常7、发卡行(或转入/转出方)的内部系统超时√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS92金融机构或中间网络设施找不到或无法达到失败发卡方线路异常,请稍后重试1、没有可用线路2、银联处理中心或入网机构的 IP 地址格式及端口号错误√√√94 重复交易失败拒绝,重复交易,请稍后重试1、用于检测到原始交易是重复的交易;2、在建立委托时发现委托关系已存在3、交易序号重复√√√96银联处理中心系统异常、失效失败拒绝,交换中心异常,请稍后重试用于表示由于银联处理中心的错误而导致交易被拒绝,由银联给出。如以下情况:1、银联处理中心无法进行正常处理,发生了诸如数据库操作失常、共享内存操作失常、函数操作失常等内部处理失败的情况2、银联处理中心维护中,拒绝所有请求√97ATM/POS 终端号找不到失败终端号未登记终端号未登记√√98银联处理中心收不到发卡方应答失败发卡方超时1、发卡方超时2、转出方超时3、接收应答超时√99 PIN 格式错失败PIN 格式错,请重新签到PIN 格式错√√√A0MAC 鉴别失败失败MAC 校验错,请重新签到MAC 校验失败√√√A1转账货币不一致失败转账货币不一致转账货币不一致√√√A2有缺陷的成功成功交易成功,请向资金转入行确认银联处理中心转发了原转入/存款/汇款交易请求,但未收到发卡方应答时,银联处理中心直接向受理方应答为有缺陷的成功交易√A3资金到账行无此账户失败资金到账行账号不正确资金到账行无此账户√A4有缺陷的成功成功交易成功,请向资金到账行确认未收到原转入/存款/汇款交易请求时,对关联的确认交易的承兑为有缺陷的成功交易√A5有缺陷的成功成功交易成功,请向资金到账行确认原转入/存款/汇款交易为拒绝时,对关联的确认交易的承兑为有缺陷的成功交易√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW ISA6有缺陷的成功成功交易成功,请向资金到账行确认银联处理中心转发了原转入/存款/汇款交易请求,但未收到发卡方应答时,对受理方发来的关联的确认交易的承兑为有缺陷的成功交易√A7安全处理失败安全处理失败1、调用 MAC 校验程序失败2、调用 PIN 校验程序失败3、PIN 转换错误4、MAC 生成失败5、密钥生成失败6、密钥启用失败7、密钥重置失败8、生成 ARPC 失败9、处理 MAC 异常时失败√√√B1无欠费(收据未打)失败此业务无欠费费用查询时使用√C1受理方状态非法受理方状态非法用于表示由于受理方的错误而导致交易被拒绝,如以下情况:1、受理方签退2、受理方运行状态无效3、受理方未签到√D1机构代码错误机构代码错误√√√D2 日期错误日期错误√√√D3无效的文件类型无效的文件类型√√√D4已经处理过的文件已经处理过的文件√√√D5 无此文件无此文件√√√D6接收者不支持接收者不支持√√√D7 文件锁定文件锁定√√√D8 未成功未成功√√√D9文件长度不符文件长度不符√√√DA文件解压缩错文件解压缩错√√√DB 文件名称错文件名称错√√√DC无法接收文件无法接收文件√√√应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW ISF1文件记录格式错误记录格式不符合规范要求√F2文件记录重复与已有的记录重复√F3文件记录不存在要求进行操作的记录不存在√F4文件记录错误对记录的其他操作出错√F5文件批量转联机未完成批量交易中文件批量转联机超时,未完成转换√√N1未登折帐目已超限,交易不成功失败未登折帐目超限未登折帐目已超限,交易不成功√Y1 成功脱机交易成功(符合 PBOC 借/贷记标准的 IC 卡专用,具体使用方法参见技术规范第三部分文件接口规范)√Y3 成功不能联机,脱机交易成功(符合 PBOC借/贷记标准的 IC 卡专用,具体使用方法参见技术规范第三部分文件接口规范)√Z1 失败脱机交易失败(符合 PBOC 借/贷记标准的 IC 卡专用,具体使用方法参见技术规范第三部分文件接口规范)√Z3 失败不能联机,脱机交易失败(符合 PBOC借/贷记标准的 IC 卡专用,具体使用方法参见技术规范第三部分文件接口规范)√播放器加载中，请稍候...
该用户其他文档
下载所得到的文件列表银联返回码（精选）.docx
文档介绍：
银联返回码应答码联网机构在遇到下表中列举的适用条件时,应使用与该适用条件对应的应答码A.27 按序号排列的应答码表应答含义终端操作终端显示(推荐) 适用条件适用角色AC SW IS00承兑或交易成功成功交易成功√√√01 查发卡方失败请持卡人与发卡银行联系发卡方原因拒绝该笔交易,只有必须要求联系发卡行的情况才使用此应答码。...
内容来自淘豆网转载请标明出处.}