Transcript 点击这里下载 - 同济大学软件学院

大型主机应用上的开放系统和中间件
2011年度教育部-IBM精品课程
同济大学软件学院
唐剑锋
[email protected]
第7章 应用CICS Web Support实现以IP直连访问主机应用



CICS Web Support（简称CWS）提供了一些CICS的服务，使得用户可以
通过浏览器的方式直接调用和访问CICS中的应用。
用户可以使用CICS Web Support中Web-aware程序来处理Web的请求与
响应。Web-aware程序指的是使用CICS Web Support提供的Web API，
例如EXEC CICS WEB和EXEC CICS DOCUMENT，来处理Web请求与响应的
程序。
应用程序可以使用CICS Web Support完成如下一些功能：
–
–
–
–


1.通过匹配请求的URL来调用相应的CICS应用；
2.解析HTTP请求；
3.构建HTTP响应；
4.构建显示在浏览器上的HTML输出文本。
尽管CICS Web Support主要是设计用来支持通过HTTP浏览器和CICS的
交互，但是它同样支持客户端的非HTTP（non-Http）的请求，例如用
socket发来的数据包。
但是不论何种情况，CICS Web Support都会使用相同的资源组件来处
理以上的两种请求。
7.1 CICS Web Support概述
7.1.1 为什么要使用CICS Web Support




CICS Web Support是CICS本身自带的处理TCP/IP请求与响应的服务，
它提供客户端通过IP直连的方式对CICS进行访问。
对于浏览器使用HTTP的通讯方式，而Socket使用非HTTP的通讯方式。
它不需要用户通过添加任何中间的连接桥（比如CTG，MQ）或者Web
Server来接入CICS。
对于用户来说它们可以开发基于HTML页面的应用，提供友好的用户操
作界面（CICS Plex Manager的Web User Interface就是基于此项技术
的实现），或者使用非HTTP的方式，直接向CICS发送TCP数据包，在
Web请求处理方面也有很大的灵活性。
如果安装Web Server或者CTG就需要增加额外的维护工作，但在CICS
Web Support中，用户完全可以通过其提供的API来灵活处理TCP/IP请
求。
7.1.2 CICS Web Support中的组件

CICS Web Support包含了如下组件：
– 1.EXEC CICS WEB API也称为CICS Web Interface，用来解析HTTP请求和构
建HTTP响应，同时EXEC CICS WEB 中的一些API也可以处理非HTTP的请求。
– 2.EXEC CICS DOCUMENT API。通过HTML模板用来构建HTML文本，用于浏览
器的显示。
– 3.文档模板（Document Template）。通过HTML代码片段来构建HTML文本，
其中用到一些符号列表，在将HTML发送给浏览器的时候动态地替换符号的
内容。
– 4.数据转换程序（Data Conversion Program）。CICS提供的转码程序
DFHCCNV，当浏览器与CICS使用不同的Code Page时对数据进行正确的转换。
– 5.BMS宏。可以将BMS Map转化成HTML文本。
– 6.Utility程序。处理HTTP的请求与响应。绝大多数都是系统程序，对于用
户是透明的。例如，Web Attach程序，Alias Transaction程序等等。
7.1.3 Business Logic Interface


Business Logic Interface 简称BLI。BLI是CICS Web Support中的
Web组件同User Program通信的接口。BLI可以将对Web请求的处理与业
务逻辑的处理分隔开来。
BLI的分层结构图如下图7-1所示：
图7-1： BLI分层结构图

在BLI模型中Converter负责处理Web请求和响应的数据。Converter分
为两部分，第一部分处理Inbound数据（decode），将请求数据转化为
Business Logic程序（也称作User Program或者Server Program）可
识别的数据结构。Business Logic程序将COMMAREA的数据传回给
Converter。Converter将此数据转化为响应数据（encode）。







在CWS中BLI的程序DFHWBBLI被Analyzer调用，Analyzer在稍后讲到。
DFHWBBLI的COMMAREA中可以指定Converter的名字，User Program的名
字，和Decode的数据。
如果Analyzer指定Converter的名字，则BLI会调用Converter。
Decode会为User Program设置COMMAREA的数据结构，然后返回BLI。随
后BLI会调用User Program将COMMAREA数据传递给User Program。
如果不指定Converter的话，BLI则将请求的数据原封不动的传递给
User Program，由User Program自己处理。User Program会更新
COMMAREA。
最后如果指定了Converter，BLI会调用Converter做Encode对客户端做
出响应。
这里需要说明的是：BLI模型在CWS中被称为non Web-aware模型。也就
是说处理请求的数据是从COMMAREA中获得，但是CWS中可以用Web API
直接得到请求数据，并且解析请求数据。
但是这对HTTP的请求来说是可行的，对于非HTTP的请求则不行，处理
非HTTP请求我们需要从COMMAREA中取得请求数据，然后自己做解析，
这在下边的非HTTP处理中会讲到。


BLI可以以CICS LINK、DPL或者EXCI的方式被调用。在CWS中Analyzer
会以CICS LINK的方式调用BLI。
以CICS LINK和DPL方式调用BLI的图例如下图7-2所示：
图7-2：CICS中以LINK和DPL方式调用BLI

外部程序以EXCI方式调用BLI的图例如下图7-3所示：
图7-3：外部程序以EXCI方式调用BLI
7.2 CICS Web Support对HTTP请求的处理
7.2.1 CICS如何处理HTTP的请求


当CICS接收到浏览器发来的HTTP请求时，CICS Web Support会启动一
系列的处理流程，然后再调用CICS的应用程序。
以下是CICS Web Support处理HTTP请求的基本流程：
–
–
–
–
1.接受TCP/IP连接
CICS通过Socket接受TCP/IP的连接请求。CICS的Socket Domain将TCP/IP
的请求派发给CICS Web Support Service来做进一步的处理。
CICS Socket Domain会启动一个长时间运行的Socket监听任务，监听任务
会监听所有定义在CICS端口上的TCP/IP连接请求。
当请求服务为CICS Web Support时，监听器会自动绑定Web Attach Task
（Web Attach Task后面会讲到），在一个CICS Region中只有一个Socket
监听任务的实例。
2.HTTP头的转码
从浏览器接收来的HTTP头的字符集通常为ASCII Latin-1（Code Page ISO
8859-1）。它们会被转换成主机使用的字符集EBCDIC（Code Page 037）。
当每一个HTTP请求到来时都会做这种字符集的转换。
–
–
–
–
–
3.分析请求
HTTP请求、HTTP头、HTTP Body都会传入Analyzer Program。Analyzer
Program主要负责解析请求（包括URL的解析），来决定：
（1）需要哪一种CICS资源来处理请求；
（2）请求数据将做什么样的代码页的转换；
（3）下边还需要哪些步骤来处理请求。
对于每一个HTTP请求都会调用Analyzer。
4.HTTP Body的转码
接收到的HTTP Body的Code Page是浏览器的Code Page。用户可以选择
将数据转换成自身应用程序的Code Page。
如果在Analyzer设置Body的转码，这一步的转化对于每一个HTTP的请求
执行一次。
这一步不是必须的，用户可以在Web-aware程序中使用CICS WEB API来
自动做转码工作。
–
–
–
–
–
5.构建CICS应用程序的输入
从浏览器接收到的HTTP的请求数据可能不符合下面应用程序（Non-Web
Aware程序）所要求的数据格式。这时用户可以用Converter程序对HTTP
请求进行Decode，构建符合应用程序要求的输入数据。
但是对于Web-aware程序来说并不需要Converter来构建应用程序的输入，
对于HTTP的请求WEB API会自动提取用户所需的数据域，比如，Http
Header、Http Body、Form Field等。
6.执行CICS应用程序
在多数情况下Analyzer和Converter会调用一个CICS应用程序来执行，
并且构建这个程序的输入数据。
7.构建HTTP的输出响应
应用程序的输出可能并不是发送到浏览器中的正确的数据格式。这时用
户可以用Converter将数据做Encode作为HTTP的响应。
同样的，对于Web-aware程序不需要Converter来构建HTTP的输出响应。
用WEB API和DOCUMENT API可以完成此工作。
–
–
–

8.HTTP响应的转码
HTTP的响应使用的是应用程序的Code Page。可能需要将响应数据转换
成浏览器支持的Code Page。
当Analyzer中指定了Code Page转换时这一步会被执行。对于Web-aware
程序可以用WEB API做Code Page的转换。
9.发送HTTP响应
进行完上述的处理流程后，CICS Socket Domain会将HTTP响应发给浏览
器。
下图7-4是对处理HTTP请求时需要用到的CISC Web Support资源的描述，
圈起来的部分表示了处理HTTP请求时资源的调用顺序，在下边的小节中
会对这些资源加以阐述。
图7-4：CICS Web Support处理HTTP请求时需要的资源
7.2.2 CICS Web绑定处理
1. Listener Transaction CWXN
– CICS Web Support可以同时监听多个TCP/IP端口。Socket Listener
Transaction CSOL负责监听每一个定义在TCPIPSERVICE中的端口。
– TCPIPSERVICE作为CICS提供的资源组件负责对监听器进行管理。
TCPIPSERVICE封装了一个TCP/IP监听器的功能。
– 尽管Socket Domain只有一个监听任务，但是使用多个TCPIPSERVICE，使得
CICS可以在同一时间监听不同端口、IP地址上的多种请求。换句话说
Socket Listener Task CSOL可以处理TCPIPSERVICE中定义的监听Socket。



TCPIPSERVICE只负责处理应用TCP/IP协议的请求，因此它必须依赖通
过CICS的Socket Domain同客户端进行通信。
但是并不是所有的TCPIPSERVICE都和HTTP请求绑定，TCPIPSERVICE还
可以处理IIOP，或者non-Http请求等。
Socket接收到它监听端口上的连接请求时，CSOL会绑定一个
Transaction，这个Transaction和此端口对应的TCPIPSERVICE相关联。





对于处理Web请求的TCPIPSERVICE，默认绑定的Task是CWXN（非HTTP的
请求是CWXU，下面小节将会讲到非HTTP请求的处理）。
CWXN是一个系统任务，它会建立Alias Transaction的上下文，Alias
Transaction则负责处理请求。
在一个CICS Region中可以有多个CWXN的运行实例，对于每一个请求都
会绑定一个CWXN的实例来处理。同时CWXN也会启动多个Alias
Transaction来处理请求。
当Socket 监听程序 DFHSOL调用DFHWBXN时，DFHWBXN会调用内部的Web
Receive Call来接收Socket监听器接收来的客户端的数据。
当收到数据以后，数据被写入TS Queue中。一共有两个TS Queue用来
存放请求的数据。
– 第一个TS Queue用来存放HTTP Header数据，并且数据是以EBCDIC形式存放
的。在将HTTP Header写入TS Queue以前将调用Code Page转化程序DFHCCNV
将ACCII码转化成EBCDIC码。
– 而第二个TS Queue用来存放HTTP请求的Body数据。这里的数据将不做Code
Page的转换，因为Body的数据需要用户自己决定如何处理。可能在
Analyzer中指定Code Page，User Program 通过BLI COMMAREA得到数据，
或者对于Web-aware程序，用户用WEB API来自己做Code Page的转码工作。









当所有的数据被写到TS Queue以后，Analyzer Program被调用来建立
Alias Transaction，User Program会在Alias Transaction下执行。
如果请求数据没有包含“Connection: Keep-Alive”的头部，CWXN在调
用完Analyzer后就被中止执行。
如果HTTP的会话是长连接的，CWXN会被暂时挂起，直到Alias
Transaction执行完以后，再被重新执行。
这时它会重新进行内部的Web Receive Call看看是否有更多的请求数
据从Socket发过来。
2. Alias Transaction CWBA
用户的Web请求最终在CICS被执行需要通过Alias Transaction。
一个Alias Transaction只能执行单一的请求，但是CWXN可以同时启动
多个Alias Transaction，每一个对应处理一个请求。
CWBA是系统默认的Alias Transaction ID，它会调用系统程序DFHWBA。
Transaction ID可以被用户在Analyzer中更改，但是初始调用的程序
总会是DFHWBA。
DFHWBA会调用BLI程序DFHWBBLI。DFHWBBLI会调用Converter 和User
Program来完成Web请求的处理。
7.2.3 CICS Web Support Analyzer

Analyzer是一个User-Replaceable（URM）Program，它负责解析每一
个从浏览器到来的请求，它会决定：
– 1.HTTP在CICS中是否被处理；
– 2.调用哪一种相应的CICS资源来处理HTTP请求；
– 3.以下HTTP的处理流程。




Analyzer可以指定处理HTTP请求的CICS应用程序的名字，Converter的
名字，Alias Transaction ID，执行Alias Transaction的USER ID，
Code Page的转换。
Analyzer在TCPIPSERVICE的URM参数中指定。
因为Analyzer是系统调用的，在定义Analyzer时需要指定ExecKey为
CICS。
Analyzer在CWXN收到Listener Transaction的请求数据后被调用。

Analyzer按照如下的格式解析HTTP请求的URL：

所有的数据域在解析的时候都被转为大写。
– 1.converter。指明了处理请求的Converter的名字，最多8个字符。
如果设定Converter的名称为“CICS”，则说明没有Converter将被
调用。
– 2.alias。指定Alias Transaction的名字，最多4个字符。
– 3.program。指定了处理请求的CICS应用程序的名字，最多8个字
符。
– 4.ignored。这部分数据域被Analyzer忽略，但是可以被
Converter来使用。
– 5.token。前8个字节被作为User Token传递给Converter，随后的
字节被Analyzer所忽略，但是可以被Converter或者User Program
所使用。
7.2.4 基于HTTP处理请求的实现






这里将给出一个具体的应用，此应用说明了如何利用CWS实现一个基于
HTML的Web应用程序，以浏览器访问的方式调用CICS中的应用。
1 . 应用程序架构及运行环境
此应用程序是一个基于HTML Web页面的应用程序。
用户可以实现登录、注册和编辑自己的注册信息的功能。
Analyzer通过解析用户从浏览器输入的URL地址，调用相应的WebAware User Program来处理HTTP的请求与响应。
同时还加入了图片处理的功能，利用Converter处理图片的显示。
同时还考虑了图片处理与消息处理的负载分配，用两个CICS Region分
别处理图片和文本消息。

应用程序架构如下图7-5所示：
图7-5：应用程序架构

应用程序运行环境如下图7-6所示：

在Web浏览器中键入如下格式的URL来调用CICS的Program：
Http://10.60.37.130:20003/CICS/CWBA/CWIINDEX
其中：
–
–
–
–
–
（1）10.60.37.130 是应用程序运行的主机名或IP地址；
（2）20003是TCPIPSERVICE中定义的端口号；
（3）CICS是Converter的名字，这里用CICS表示不需要Converter；
（4）CWBA是Alias Transaction的名字；
（5）CWIINDEX是Web-aware Program的名字。





2. 应用中的CICS Web Support资源
– （1）TCPIPSERVICE
– （2）Analyzer
– （3）User Program
– （4）HTML DOCUMENT Template
DOCUMENT Template在CICS中可以以RDO的方式来定义，CICS中用专门
的DOCUMENT Handler Domain来管理DOCUMENT Template。
DOCUMENT Template可以存放在VSAM、TS Queue、TD Queue、DFHRPL的
Load Library、PDS数据集或者内存中。为了便于管理，对于较大的
DOCUMENT Template一般都存放在PDS数据集中。
对于用PDS数据集来存放DOCMENT Template，需要在CICS Startup JCL
中指定DD语句来指定PDS数据集的位置，例如可以用如下的DD语句指定
DOCUMENT Template的PDS数据集：
需要说明的是对于定义DOCUMENT Template存放的形式，上面的说到的
File、TS Queue等是互斥的，也就是说只能用它们中的一个来存放
DOCUMENT Template。
在CICS Web Support中用DOCUMENT Template来存放HTML页面的模板，
此模板中包含了静态的HTML页面代码和需要动态显示的符号列表，这
些符号在CWS构建HTTP响应时被Web-aware程序动态地替换成HTML文本。


3. 设计Web-aware程序结构
典型的Web-aware程序处理请求和响应的流程是：解析TCP/IP请求，解
析HTTP请求，得到HTTP Body中的数据，抽取HTML Form中的数据，构
建HTML模板，替换模板中符号列表的符号值，构建相应的HTML文本，
对客户端做出响应。
Web-aware程序的程序结构图如下图7-7所示：
图7-7：Web-aware程序的程序结构



4. 应用中的CICS Web Support API
CICS Web Support API一共有三类：TCP/IP API，WEB API，DOCUMENT
API。这里只对应用中的API做一下介绍。
（1）TCP/IP API
WEB程序或者IIOP程序可以通过TCP/IP API获得关于客户端和服务端的
TCP/IP信息。API如下：
（2）WEB API
WEB程序可以通过WEB API处理HTTP请求和响应。
1）获得HTTP相关信息的API如下：
2）获得HTTP Header信息的API如下：
3）得到Body数据（User Data）的API如下：
4）发送HTTP响应，通过将DOCUMENT Template的数据转化成HTTP Body
发送给客户端，API如下：
5）抽取HTML Form中的数据。由于Form存在于Body中，所以在调用此
API之前必须先执行EXEC CICS WEB RECEIVE。在执行此API时，会自动
根据HTML Form Field 的名字来提取相应的数据。API如下：





（3）DOCUMENT API
可以通过DOCUMENT API创建和处理以多种方式储存的HTML文档，并且
可以做符号替换。
在介绍DOCUMENT API前先介绍符号列表（Symbol Lists）。
符号列表是符号的集合，每个符号以&号开头，以;结尾。每个符号除
去&和;最多可以有32个字符。可以是任意字母数字，大写或者小写或
者有下划线，但是中间不能有空格。
DOCUMENT API 根据传入的符号列表对DOCUMENT Template做符号的替
换。
下图7-8是一个符号列表的例子，以及如何给符号赋值，并作符号替换。
<html>
<html>
<head>
<head>
<title>
<title>
给符号分配值
产生
HTML
页 Andrew
&firstn;
firstn=Andrew
&
lastn
=Jones
&lastn;
Jones
</title>
</title>
</head>
</head>
</html>
</html>
HTML Document Template
HTML Page
图7-8 符号的转换




构建新的文档。可以指定以什么形式建立文档。
如果从内存中建立则使用FROM参数，传入文档模板的字符串；或者指
定Template参数，从文件或者Queue中构建文档。
在执行此API的时候会进行模板中符号的替换。
此API会返回一个DOCTOKEN，在WEB SEND API中根据DOCTOKEN来构建
HTTP的响应数据。API如下：




5. 图片处理
基于HTML的Web应用必然要涉及到图片的显示处理问题。在CICS
Web Support中由于我们采用的是IP直连的方式，无法借助HTTP
Server来处理图片的显示，所以这里我们采用解析程序
（Converter）来处理图片的显示。
前面介绍了Analyzer如何处理解析HTTP请求的URL，根据URL的
格式我们设计一个请求的字符串。在处理图片的显示时，调用
Converter的同时指明我们图片的名称和扩展名。
根据以上URL路径构造的一个请求的字符串：“/graphix/head.jpg”。
我们指定graphix为Converter程序的名字，head为要显示的图片的名
字，jpg为图片的扩展名。
根据以上构想，我们要解决的问题就是：
（1）Converter的调用。在Analyzer中根据请求的URL得到图片处理的
Converter的名称，调用Converter，同时不需要用Alias调用User
Program。
（2）图片的存储。这里我们用之前介绍的DOCUMENT TEMPLATE来存放
图片。
我们可以将图片以二进制格式存放到MVS的Dataset中，在定义
DOCUMENT TEMPLATE时指定Type为Binary，存放的存储介质为Dataset。
这里之所以选用Dataset是因为图片是一种相对较大的文件，如果以
TDQ的方式存放的话，虽然会在一定程度上提高处理效率（从内存中直
接读取），但容量大小不能超过32760个byte，而Dataset几乎可以存
取任意大小的文件。
（3）效率的考虑。因为图片的处理相对页面的字符处理和请求消息的
处理来说负载较大，所以这里考虑用另外一个CICS Region来单独处理
图片的显示，就好像模拟一个HTTP Server一样，这样就会把图片处理
与请求消息的处理分开，降低了单一CICS Region的负载，大大提高了
效率。

下图7-9为负载解决方案的示意图，一共有两个CICS Region，在图片
处理的CICS Region中单独定义一个TCPIPSERVICE用于图片请求的处理。
图7-9：图片处理的负载分配图

下面论述图片处理的各个步骤：
（1）Analyzer中调用图片处理Converter的COBOL代码如下：
（2）图片处理的Converter的实现：
–
–
–
–
–
1.获取HTTP请求的URL路径，例如，/graphix/head.jpg；
2.根据URL路径分离图片的名称和扩展名；
3.根据图片的名称建立相应的存放图片的DOCUMENT TEMPLATE；
4.构建相应的HTTP Header，指定Contenttype Value为imag/扩展名；
5.将建立好的存放图片的DOCUMENT TEMPLATE发给浏览器。
（3）存放图片的DOCUMENT TEMPLATE在CICS中的定义如下图7-10所示。
这里 Templatename为要显示的图片名称，存放介质为PDS数据集中的
Member，属性中Type为Binary。
图7-10 DOCUMENT TEMPLATE在CICS中的定义
（4）图片处理CICS Region的TCPIPSERVICE的定义如下图7-11所示。
这里需要指定一个和消息处理CICS Region中不同的TCPIP端口号，同
时在属性URM中需要指定一个不同Analyzer来实现Converter的调用。
图7-11 TCPIPSERVICE在CICS中的定义
6. 实现场景

以下是本应用实现之后的场景。用户登录主页以后可以选择注册新的
用户，或者用已注册好的用户名和密码登录之后进行信息的编辑。界
面如下图7-12所示：
图7-12 本应用实现之后的场景界面
7.3 CICS Web Support对非HTTP请求的处理






CICS Web Support支持对非HTTP请求的处理。
在一些场合中，用户的客户端程序是通过Socket同CICS进行通讯，这
里并不是使用HTTP协议，仅仅是发来Socket的TCP数据包。
在前面的CICS Web Support中介绍过，对于非HTTP的请求CICS Web
Support仍然会使用相同的CICS资源组件对其进行处理，但是Analyzer
中处理的方式将会同HTTP的有所不同，而且只支持EXEC CICS WEB
SEND API用来对客户端进行请求的响应和DOCUMENT API用来构建文档，
其他的WEB API将无法使用，特别是我们无法用WEB RECEIVE来得到请
求的数据。
非HTTP的处理并不属于Web的处理，但在现实中却经常使用，比如目前
的银行ATM系统或者一些3270终端的系统和远程Server的通信，它们都
不会发HTTP请求的数据包。
如果和CICS进行通信的话可能会使用MQ或者CTG的方式，但是这无疑增
加了维护上的开销，所以应用CICS Web Support的方式可以进行
TCP/IP的直连，无疑对客户来说节约了很大的成本。
与HTTP处理不同的是非HTTP的处理用到的Web Attach Task是CWXU，但
是它仍然会调用Web Attach程序DFHWBXN。

非HTTP请求处理调用的CWS资源组件如下图7-13所示：
 CWS非HTTP的处理流程图如下图7-14所示：
图7-13：非HTTP请求处理调用的CWS资源组件
图7-14：CWS非HTTP的处理流程
7.3.1 TCPIPSERVICE的定义

在TCPIPSERVICE的定义中我们将指定Protocol参数为User，
Transaction为CWXU。如下图7-15所示：
图7-15 TCPIPSERVICE在CICS中的定义
7.3.2 非HTTP请求Analyzer的实现

非HTTP请求的Analyzer中将不会指定如下的输入数据域：
–
–
–
–


HTTP版本
Method
Document path
请求数据头
请求数据会被分成几部分在网络中传输。对于非HTTP请求，CICS在调
用Analyzer以前将不会对请求的数据加以重构处理，例如不会将HTTP
请求的数据头部和Body分开，而是原封不动的将User Data传给
Analyzer。
在User Data进入Analyzer的时候被拆成两部分，而每一次调用
Analyzer只会收到其中的一个部分，所以我们必须连续地调用两次
Analyzer才会将User Data完全地得到，随后才可以调用User Program
来处理得到的User Data。




在这里我们需要在第一次调用Analyzer的时候指定Analyzer的返回码
为URP_EXECPTION，Reason Code为URP_RECEIVE_OUTSTANDING。这样
CICS Web Support会在第一次调用Analyzer的基础上进行第二次的调
用，得到User Data的另一部分。
由于使用COMMAREA来获得请求数据，所以最大的字节数不能超过32767
个字节。
由于我们无法用WEB RECEIVE来做Code Page的转化，所以在Analyzer
中我们自己做Code Page的转换。
以下是Analyzer中关键技术的C语言实现代码。
7.3.3 User Program的改变——应用BLI接口获得请求数据




由于我们无法用WEB RECEIVE API获得请求的数据，这里我们将用到前
面介绍的从BLI的COMMAREA中取得数据。
由于我们在Analyzer中做了Code Page的转化，所以在User Program中
我们不需要做任何的Code Page的转化，我们需要定义一个指向BLI
COMMAREA的指针来获得请求的数据。
以下为实现的部分C语言代码。
对于请求的响应这里我们仍然可以用CICS WEB SEND并指定Code Page，
同HTTP的处理没有区别。
7.3.4 CWS非HTTP请求的应用实现




以上我们解决了非HTTP请求中Analyzer接收数据的问题，通过CICS
Web Support中的全局指针判断接收数据的长度，来实现连续两次调用
Analyzer，同时完成了Code Page的转码，并在User Program中应用
BLI接口获得从Analyzer传来的请求数据。
以下的应用通过Windows上的Java Socket程序向CICS发送TCP的请求数
据包，CICS得到数据包后对Java客户端做出相应的响应。
根据CWS处理非HTTP请求的原理，在User Program中用DFHWBBLI来得到
请求数据，然后用WEB SEND API向Java端做出响应。
CWS非HTTP请求的应用程序架构图如下图7-16所示：

以下是Java端的部分实现代码和返回结果：

在CICS端我们利用TSQ将非HTTP处理中程序的调用记录下来，如图7-17
所示。可以看到，在调用User Program之前，CWS对Analyzer重复进行
了两次调用，第一次收到1byte的数据，而第二次收到了完整请求的
4byte数据（请求为字符串：mike）。
图7-17：TSQ中记录的非HTTP调用处理过程