利用cmd对tomcat进行重启操作

首先是业务背景：

深交所与中国结算基金盘后业务整体技术方案[/b]





说明：

1. 参与人：深交所，中国结算, 基金销售人（含券商，直销，银行及其他类特别销售机构，分别以法人为单位接入通信系统），基金公司及深圳证券通信公司。各类参与人使用的编码规则采用目前场外基金销售统一编码规则，本系统不再另行制定。
要强调的一点是，接入该系统中的基金销售人必须具有基金代销资格，没有销售资格的券商是不能通过本系统申报各种业务的。

2. 具体操作流程说明：如图，不同颜色的线表示不同的时序和不同类型的数据流（序号表示前后时序关系） ：
① 每日早8：00点前，管理人将当日的基金行情数据（含净值，各类交易状态，及各种特殊类业务的单独控制状态[不受基金状态的控制，如分拆合并等]，注意该文件不同于管理人发送给TA系统的行情文件）以文件的方式发送到实时系统中；8：30点实时系统收集全部的基金的行情数据后，利用深证通，向全部销售销人发送全部基金的行情数据（以文件方式，注意是实时系统中的全部基金，不区分是否代销），销售人根据行情文件可以做前端业务控制。
对于实时系统中挂牌交易的基金（父，子基金）都要求在TA系统中存在，以便于系统整体参数维护。
② 9:30-15:00,券商利用深证通的API实时报送基金的交易，实时系统在接收到数据后，同时经过合法性检查，检查的项目主要有
A. 数据格式，业务包含有效必须字段；
B. 代理人权限主要指能否做特殊类业务；
C. 基金状态及特殊类业务控制状态。
对检查通过和没有通过的都要返回处理结果，该部分称为预处理结果，用返回代码‘0000’表示预处理成功，否则表示失败信息。对每一条消息，系统都要返回预确认结果，系统能重复发送该结果。
③ 15:00, 实时系统接收TA发送当日回报数据（针对前一日申购赎回业务及管理人发起业务），同时汇总当日申请数据，对T+0过户类如分拆合并类业务进行处理，最终生成当日场内份额变更库[包换当日全部申请数据]，16:00发送给深圳分公司。
分公司对该库中全部记录的证券账户首先做合法性检查，然后对账户份额检查，通过进行过户操作，份额变更分如下情况：
A. 份额调减（基金分拆合并，T-1日赎回和基金转换转出确认等）
B. 份额调增 （基金分拆合并，T-1日申购和基金转换转入确认等）
C. 份额锁定或冻结（T日赎回及基金转换等）
D. 份额解锁或解冻 （T-1日赎回或基金转换失败等）
E. 份额无变化（T日申购类等）
对于过户的顺序以发送数据的序号从小到大逐一处理（业务上T-1日确认，T日分拆合并，T日申购赎回等顺序）
特别要注意的是对于分拆合并及基金转换等业务，发给分公司数据是以组为处理单位（如三条记录为1组）,分公司必须是对组内记录要同时增减份额都要成功才认为成功，如有任意一条记录过户失败，该组记录都做失败处理。
同时，要根据交易数据，生成当日账户数据发送给TA系统。对于实时系统中挂牌的基金，分公司每日也要把份额文件发送到TA以便于TA系统转发给基金管理人。
深圳分公司将过户结果在18:00前反馈实时系统。
④ 深圳分公司将当日的份额变更及余额发送给券商和交易所（份额最终登记结果以深圳分公司为准） ，实时系统根据分公司份额过户结果，生成当日回报文件，通过深证通向销售人发送回报文件（用于清算）。
⑤ 对于当日实时系统接收的申请，将以内部申请文件的形式发送给TA系统，对于T+0过户的，TA系统在待确认中以通知的形式发送，对需要管理人计费或确认的数据参照目前TA与管理人之间的操作。

附：FAQ

1. 问：深交所为什么要实施基金盘后业务技术改造方案？
答：由于现行LOF业务平台的申购赎回等盘后处理的指令申报通过深交所的报盘接口进行申报，而深交所并不进行任何处理，只是绕交易系统转发给结算公司。由于深交所报盘接口字段不足，严重限制了场内基金业务功能的扩展，如申购赎回的参数设置受限、无法申报基金转换、分级基金的拆分合并等业务指令，不利于深市基金业务的发展。鉴此，深交所与中国结算拟对LOF业务平台进行技术改造，将现行通过交易所进行的申购赎回等盘后处理的报盘指令改为由基金代销人直接向TA系统报盘，进一步完善深市基金业务平台功能，以便更好地适应未来基金产品创新与业务发展需求。

2. 问：基金盘后业务技术改造完成后是否将现行所有LOF的通过交易所的场内申购赎回业务移到基金盘后业务平台处理？
答：为保障业务平稳运作，前期新平台只做新业务，如拆分合并。待基金盘后业务技术平台运行平稳后，深交所与中国结算将统一部署，把所有LOF的盘后处理业务均移至基金盘后业务平台，而且将来基金的所有盘后处理业务（如申购赎回等）均通过上述平台运作。

3. 问：8:30点实时系统收集全部的基金的行情数据后，利用深证通，向全部销售销人发送全部基金的行情数据（以文件方式，注意是全部基金，不区分是否代销）。如果券商只代销部分基金，那全部基金的行情数据是否要券商自己区别?
答： 一般情况下，场内有销售资格的券商对场内基金都有代销关系，这与场外基金代销是不同的。
注意，这里所说的基金是只包含通过实时系统进行业务申报的基金数据，与场内场外基金无关。

4. 问：深圳分公司将过户结果在18:00前反馈实时系统，深圳分公司将当日的份额变更及余额发送给券商和交易所。这里发给券商的是什么格式，是否用于对账?
答：目前该文件已经存在了，具体可以咨询深圳分公司(股份变更库和余额库)。券商做场内LOF的申购赎回时是能收到该对账文件的。

5. 问：实时系统根据分公司份额过户结果，生成当日回报文件，通过深证通向销售人发送回报文件（用于清算）。T日的所有委托是否会都会给个确认?比如当日的申购赎回等
答：T日的委托要按业务性质区别回报时点。对于合并分拆类业务，份额需要在T日过户（T+0过户）这些业务在T日的回报中是包含的。对于申购赎回类业务，由于要涉及管理人确认和计费处理，是在T+1回报文件中进行确认的（这类业务的处理和当前LOF场内申购赎回处理模式相同）。

6. 白天撤单预确认是否能当成功?
答： 撤单被确认可以当作成功，对于撤单业务，在当天的回报数据中也会体现。

7. 盘后交易系统中涉及的资金清算如何处理。
答： 对于实时系统上线初期，新业务并不涉及资金清算。但如果以后场内LOFS申购赎回业务统一转到新平台上来申报时，对于资金清算模式，与目前深交所LOF场内申购赎回涉及的资金清算问题处理方式相同，都是采用场内合并到场外开放式基金清算系统中进行清算和资金交收的，这点对参与人没有变化。变化的是清算文件，目前的LOFS确认文件该被方案中的回报文件所取代。

8. 新返回的交易回报文件与原来登记公司提供的LOFJS文件有何相互关系？
答： 2个文件性质相同，但如果业务申报途径没有发生改变，2个文件是各自独立，各自只针对各自渠道申报业务进行回报的。但当场内申购赎回业务也转到这个平台时，LOFJS就没有数据了，自然也就没用了。对于同一种业务，只能通过一条业务途径申报，不存在2个系统（申报途径）同时做相同业务的可能。

9. 券商利用深证通的API实时报送基金的交易，软件开发商进行开发时提供何种开发方式？软件开发商需要知道开发方式和支持的开发语言，交易所是否可以提供通讯组件等？
　　答：通讯方面的资料可以到深圳证券通讯公司网站下载，这是公开的技术资料，如果有具体技术问题，可以咨询 0755-88352793

最后说一下基金盘后业务作为券商交易系统的配置。

现在所说的基金盘后业务，其实是跟三方存管共用的一个消息传输系统。程序就叫做MR。MR小站可以复用，即只要是该公司的交易系统，都可以通过自身交易系统的基金盘后交易菜单报送基金盘后业务到深证通，因为使用的都是相同的参数，详细参数如下：
UserID、AppID、AppPasswd是深证通分配给证券公司的用户ID、应用ID、应用密码。
DestUserID、DestAppID是深证通分配给证券公司的目标用户ID和目标应用ID，即处理用户请求的目标
一般还需要加上MR小站的IP和端口。
还需要加上本公司的基金代销人代码，一般为三位。
设置好后连接MR程序，即可以发送基金分拆与合并的委托，回报会以报文形式回复，当系统内委托状态为已报时，说明系统设置正确。
当天下午五点左右深证通会发回来回报文件：scdXXXXXXXXXXhb.dbf。
可以用来清算，或者用sjsgf文件来清算。
本次实施过程中前期因为缺少沟通导致一直误以为需要申请新的账号而延误了一段时间。后来又因为失误配错了基金代销人代码。导致回报缺少当日所发的基金拆分信息。而公司的大柜台系统是用该文件来清算的。导致了证券余额不对。需要手工调账了。。。悲剧。。。但是这个是不影响清算的，因为深交所过户的时候只看席位信息和股东信息。还算是万幸。没有影响到交易。
不过又有了新问题，因为和公司大柜台的源应用ID是一样的，导致了现在无法收到回报报文，但是委托是发过去了，需要找中登那边添加一个新的源应用ID才可以收到回报报文。中登电话打了两天没打通了。。。
目前已经更改源应用ID了，与原来的柜台系统不一致即可，不过需要在MR上面配置一下，有两行
jjph01=1
jjph01=16
第一个是源应用ID和密码
第二个是源应用ID和业务类型
配完后就可以收到中登发回来的实时回报了。

本文出自 “技术心得” 博客，转载请与作者联系！