-
变量名 注释 CCFLAGS CICS开放平台中,它同时设置编译和链接的选项。在windows中指定C编译器的编译和链接 cell_admin_pw 包含DCE cell管理员的DCE密码 CICS_ANIMATOR_TIMEOUT 控制Micro Focus Server Express COBOL program to attach to Animator的时间。设置-1为等待;值0意味着不等待。建议查看CICS Application Programming Guide CICS_BROWSE_CACHE 指定4KB大小页浏览器的缓存数量 CICS_CST_HTML 指定CICS提供交易的HTML帮助路径和目录。 CICS_DUMP_STORAGE_CHAIN (CICS for Windows) 在windows平台中,设置此值为t:TranID f:FileName来容许诊断数据集中在不同的文件来替代集中在内存堆栈 CICS_ECINODELETETERMINAL 若是设置此值null以外的值,可以防止删除终端错误时ECI程序链接调用。这个参数应用域ECI程序,不是CICS的环境变量 CICS_FTOD_FILETYPE_BINARY (CICS for Windows) 控制cicsddt和ftod命令读的文件。若是设置了,导致文件读取时使用二进制模式替代ASCII字符模式(默认为字符模式)。 CICS_HOSTS 包含以空格分割的hostname用来在启动CICS终端时搜索regions(域) CICS_IBMC_FLAGS 在windows中指定在使用IBM C++ 编译器通过cicstcl编译和链接时的用户自定义标记 CICS_IBMCOB_FLAGS 指定在使用IBM COBOL 编译器通过cicstcl编译和链接COBOL程序时的用户自定义标记 CICS_IBMPLI_FLAGS 指定在使用IBM PL/I编译器通过cicstcl编译和链接PL/I程序时的用户自定义标记 CICS_KEEPONDELETINGCONNECTION 若是设置,则application server会等待链接删除 CICS_LEAKDEBUG 若是设置此值,将激活关于内存和文件描述符泄露产生的报告 CICS_MSC_FLAGS 只在windows中使用,指定在使用Microsoft C++ 编译器通过cicstcl编译和链接时的用户自定义标记 CICS_PPCGWY_SERVER 指定PPC gateway服务器的名称。在使用cicsppcgwy命令时没有指定server名称时生效 CICS_PPCGWY_SIZE 指定PPC gateway逻辑卷的大小(单位MB) CICS_PPCGWY_VG 指定PPC gateway逻辑卷的卷组 CICS_PROGRAM_PATH 指定当程序装载时用户定义程序的路径和搜索路径。这个环境变量生效在:
当程序无法找到时
当你在region的目录下或者region的文件中以及region bin目录中使用绝对路径,相对路径时
在程序的定义中使用这个路径信息必须不再包括任何目录信息(譬如,字符串在UNIX系统中包括任何斜杠(/),或者在windows系统中包括反斜杠(\),这些都不行)
这个变量支持标准的操作系统路径设置。这意味这在windows系统中以分号(;)间隔,在UNIX系统中使用冒号(:)间隔。CICS_SCHEMA 设置默认工作的schema文件 CICS_SFS_DATA_SIZE 指定SFS逻辑卷的数据大小(单位MB),这个变量覆盖环境中设置的CICS_SFS_SIZE变量 CICS_SFS_DATA_VG 开放平台中,这指定SFS数据逻辑卷的卷组;在windows中指定SFS数据逻辑卷的所在位置。这个变量覆盖环境中设置的CICS_SFS_VG变量 CICS_SFS_LOG_SIZE 指定SFS逻辑卷的日志大小(单位MB),这个变量覆盖环境中设置的CICS_SFS_SIZE变量 CICS_SFS_LOG_VG 开放平台中,这指定SFS日志逻辑卷的卷组;在windows中指定SFS日志逻辑卷的所在位置。这个变量覆盖环境中设置的CICS_SFS_VG变量 CICS_SFS_SERVER 设置默认SFS。这个变量覆盖环境中设置的ENCINA_SFS_SERVER变量 CICS_SFS_SIZE 同时指定SFS数据和日志两个逻辑卷的大小(单位MB) CICS_SFS_VG 在开放系统中,指定SFS的数据和日志两个逻辑卷的卷组;在windows中指定他们的位置。 CICS_SUPPRESS_BAD_USER 当CICS访问使用错误的用户将不会报出信息,既若设置此值,CSMT.out信息中将不会出现 ERZ045006W ("User identity 'userID' is not defined in this region. PUBLIC access granted.") CICS_SUPPRESS_XAOPEN_STRING 防止region(域)在尝试连接XA相关数据库时,XA OPEN的字符串显示在CICS控制台文件中(console) CICS_XA_OPEN_RETRY_DELAY 指定xa_open 操作的重试的等待时间。此值可以设置从2到15。默认的值为2。设置值超超越2到15范围则意味还是2。
此变量与CICS_XAOPEN_LIMIT协同工作CICS_XAOPEN_LIMIT 指定xa_open 操作的重试次数。此值可以设置从1到49。默认的值为3。设置值超超越1到49范围则意味还是3。
此变量与CICS_XAOPEN_RETRY_DELAY协同工作CICS_XDT_SERVER 指定默认的CICS使用数据库。此值覆盖环境设置的CICS_SFS_SERVER变量 CICS_XFH_ COMMITINTERVAL 若是外部文件句柄运行在非交易事务模式(环境变量CICS_XFH_TRANMODE设置为"N")环境变量CICS_XFH_COMMITINTERVAL指定可以在完成数据库操作前获取回滚的数量。若是CICS_XFH_COMMITINTERVAL没有设置,没个修改都会提交 CICS_XFH_DBNAME 指定DB2数据库使用的外部文件句柄。若是未设置此值,默认的DB2数据库将被使用 CICS_XFH_LOCAL_ INDEXED (CICS for Windows) 在windows的平台下CICS若使用DB2做为文件管理器。若是用户希望MF COBOL 掌控外部索引类型的文件而不是DB2,则设置此参数为1(晕,自个都看不懂) CICS_XFH_LOCAL_ SEQ (CICS for Windows) 在windows的平台下CICS若使用DB2做为文件管理器。若是用户希望MF COBOL 掌控外部sequential类型的文件而不是DB2,则设置此参数为1(晕,自个都看不懂) CICS_XFH_LOCAL_LINE_SEQ (CICS for Windows) 在windows的平台下CICS若使用DB2做为文件管理器。若是用户希望MF COBOL 掌控外部line sequential类型的文件而不是DB2,则设置此参数为1(晕,自个都看不懂) CICS_XFH_LOCAL_RELATIVE (CICS for Windows) 在windows的平台下CICS若使用DB2做为文件管理器。若是用户希望MF COBOL 掌控外部关系类型的文件而不是DB2,则设置此参数为1(晕,自个都看不懂) CICS_XFH_LOGFILE 定义外部文件句柄alternate log的路径名称。正常情况下这个参数毋须设置,外部文件句柄指向tmp目录下的一个文件叫做xfh.LogFile。若是这个文件不存在,则创建它。多个并发外部文件句柄程序可以使用同一个文件。若是你不想使用这个log文件。只是这个环境变量为NONE。生效后错误指向stderr(标准错误输出) CICS_XFH_TRANMODE 定义交易事务 ‘T' 或者非交易事务访问数据库。默认的选项是非交易事务。更多关于这两者的访问模式既实现信息见CICS Application Programming Guide。 CICS_XFH_USERNAME 定义使用连接数据库的用户名。 CICS_XFH_USERPASS 定义使用连接数据库的密码。 CICSCOL 指定cicslterm命令的默认颜色映像文件的名字 CICSDB2CONF_BIND_UR 指定是否CICS可以从DB2数据库中执行"dirty reads",这意味这不论数据库的行是否因为更新而锁定都可以被CICS读。若要准许"dirty reads"需要设置此变量为1 CICSDB2CONF_CONNECT_USER 为cicsddt,cicsivp和cicsdb2conf命令指定DB2 UDB 用户ID CICSDB2CONF_CONNECT_USING 为cicsddt,cicsivp和cicsdb2conf命令指定DB2 UDB 用户密码 CICSDB2PASSWORD 指定使用cicsdb2conf命令的DB2 UDB密码 CICSDEBUGENV 指定一个文件包含IBM Application Debugging 程序的默认值 CICSECIANIMATE 指定ECI命令使用终端且以空格分割的TTY列表。这个参数在ECI程序运行环境中有效,不是CICS的环境变量。查看CICS CICSECIMAXLUW 限制当前ECI sessions的数量。这个参数可以设置从1到200。默认值是16.这个变量用用ECI程序运行的时候,不是CICS环境变量 CICSEPIANIMATE 指定EPI命令使用终端且以空格分割的TTY列表。这个参数在EP程序运行环境中有效,不是CICS的环境变量。查看CICS Family: Client/Server Programming manual(客户端/服务器编程手册) CICSEPIMAXTERMINALS 控制程序创建的线程数量。这个变量可以设置从1到500.默认的值是100。这个环境变量需要设置在EPI客户端程序中,并不推荐设置在CICS region environment文件中 CICSEXTERNALTRACE 若是设置此值为null以外值,会导致CICS客户端和离线工具写外部(操作系统)事件性能跟踪 CICSKEY 指定当使用cicslterm命令时默认的映像文件 CICSPATH 指定CICS产品的根目录。在开放平台中默认的值是/opt/cics。在AIX中默认的值为/usr/lpp/cics。在Windows中默认值为d:\opt\cics。这个环境变量是有安装进程指定不能做修改。 CICSREGION 设置默认工作的region(域) CICSTERM 若是在当前环境下设置,CICSTERM则用来替代TERM CICSTRACE 可以用来设置或者覆盖RD stanzas定义的跟踪(trace)选项。格式模仿命令行。 DB2DBDFT 包含默认DB2数据库的名称 ENCINA_AUTHN CICS先决条件中这个参数不能被设置。定义当DCE使用RPC到Encina server时DCE(包括Encina客户端和服务器)使用的保护级别 ENCINA_AUTHZ 定义是否需要Encina server通过设置在服务器的访问控制列表(ACLs)来检查任何客户端发送来的RPC请求。需要授权检查为ENCINA_AUTHZ=1若是不需要则为ENCINA_AUTHZ=0 ENCINA_BINDING_FILE 指定不使用DCE服务时绑定交易的位置。对于CICS一般总是设置为
VarDir/var/cics_servers/server_bindings或者
VarDir\var\cics_servers\server_bindings.ENCINA_CDS_ROOT Encina server注册在DCE cell目录服务(CDS)的名字。每个server不同种类注册在子目录中的名字都定义在ENCINA_CDS_ROOT(什么哦,搞不懂) ENCINA_GWY_SERVER 默认的gateway server名称;当-server 选项在使用Encina管理命令时没有指定时生效 ENCINA_KEY_FILE 指定一个keytab文件,包含Encina Server使用DCE principal所要使用的密码 ENCINA_MIN_AUTHN 定义最小的DCE 保护级别,准许接受Encina server认可的RPC请求。它的值为0-6,若是ENCINA_MIN_AUTHN=1,服务不能在RPC中履行授权检查,所以需要设置为0。 ENCINA_PRINCIPAL Encina server使用的DCE principal的名称,譬如,SFS ENCINA_SFS_SERVER 为Encina的sfsadmin 命令设置默认SFS Server ENCINA_TK_SERVER 为Encina的tkadmin 命令设置默认SFS Server ENCINA_TRACE 指定需要产品跟踪的Encina组件。譬如,要获得Encina toolkit交易组件的产品跟踪。需要指定: export ENCINA_TRACE=tran:0x1f LANG 这个参数主要设置CICS运行的环境语言。region(域)的环境可以设置为标准的语言环境(譬如,LANG=en_US或LANG=C)或者region(域)的environment文件也可以复写这个变量。客户端(譬如,cicsterm)则会使用当前环境变量中设置的值。 LIBPATH (CICS for AIX) 只在开放平台支持。若是你使用 Micro Focus Server Express COBOL level 3.2.27 或以上的,LIBPATH 需要设置为 $COBDIR/coblib (by cicsmkcobol). 否则则不需要设置。 MSQL_DEAD (CICS for Windows) 当Microsoft SQL Server 遭遇到交易死锁,他会停止交易并使XAID无效。这将产生XA_ROLLBACK并返回RMER_NOTA(-4)。CICS认为负数返回是重大的错误并异常终止region(域)abendcode为 U8030。除非环境变量MSQL_DEAD设置为1。
若是环境变量MSQL_DEAD设置为1CICS会改为只异常终止application server。若要激活这个MSQL_DEAD=1选项必须在region的environment文件里定义PATH 这个变量需要包括CICS,Encina和DCE的bin目录
默认的值为:
$CICSPATH/bin:$OPT/encina/bin:$OPT/dce/bin(HP-UX下为$OPT/dcelocal/bin)
这里的$OPT在AIX中为/usr/lpp,而其他开放平台为 驱动器:\opt(主要指windows)
$CICSPATH在AIX中为/usr/lpp/cicsSHLIB_PATH (CICS for HP-UX) 只在开放平台支持。若是你使用 Micro Focus Server Express COBOL level 3.2.27 或以上的,SHLIB_PATH 需要设置为 $COBDIR/coblib (by cicsmkcobol). 否则则不需要设置。 TERM 当终端自动启动时指定使用终端的类型。此参数可以在用户的环境里设置 -
Const 和指针
1 const修饰指针名称,指针指向的地址不可变,但地址的内容可变,也可直接操作地址改变其内容。
例:
#include <stdio.h>
int main()
{
char c='!';
char d='w';
char* const charPtr = &c;
charPtr = &d;return 0;
}
[walter@fedora9 cprogram]$ gcc -o out pointertest.c
pointertest.c: In function ‘main’:
pointertest.c:8: error: assignment of read-only variable ‘charPtr’
2 const修饰整个声明,则不能通过该指针改变地址空间的值。
#include <stdio.h>
int main()
{
char c='!';
char d='w';
const char* charPtr = &c;
*charPtr = 'm';return 0;
}
[walter@fedora9 cprogram]$ gcc -o out pointertest.c
pointertest.c: In function ‘main’:
pointertest.c:8: error: assignment of read-only location ‘*charPtr’
-
长久以来,对依赖,关联和聚集之间的关系一直搞不清,在google上搜了下,找到了孙卫琴对三种关系进行区分的一篇文章,这篇文章用生动的语言分析了这三种关系各自的特点。适用场合,并且比较了它们之间的区别。在这里我概括一下:依赖关系:描述的是两个独立系统之间的关系,一个系统要使用另一个系统的服务,但是两者之间的这种使用关系是暂时的。关联关系:也是描述的两个独立系统之间的关系,但它们之间的关系是相对固定的。聚集关系:体现的是整体和部分的关系,一个系统由另一个系统组成。本人理解的难免有误,为了让大家体会原作者的真实意图,将原文贴在下面了:
在建立对象模型时,很容易把依赖、关联和聚集关系混淆。当对象A和对象B之间存在依赖、关联或聚集关系时,对象A都有可能调用对象B的方法,这是三种关系之间的相同之处,除此之外,它们有着不同的特征。
1.依赖关系的特征
对于两个相对独立的系统,当一个系统负责构造另一个系统的实例,或者依赖另一个系统的服务时,这两个系统之间主要体现为依赖关系,例如生产零件的机器和零件,机器负责构造零件对象。再例如充电电池和充电器,充电电池通过充电器来充电。再例如自行车Bicycle和打气筒Pump,自行车通过打气筒来充气。图1-39为Bicycle类与Pump类的类框图。
图1-39 Bicycle类与Pump类的依赖关系Bicycle类和Pump类之间是依赖关系,在Bicycle类中无需定义Pump类型的变量。Bicycle类的定义如下:
public class Bicycle{
/** 给轮胎充气 */
public void expand(Pump pump){
pump.blow();
}
}
在现时生活中,通常不会为某一辆自行车配备专门的打气筒,而是在需要充气的时候,从附近某个修车棚里借个打气筒打气。在程序代码中,表现为Bicycle类的expand()方法有个Pump类型的参数。以下程序代码表示某辆自行车先后到两个修车棚里充气:myBicycle.expand(pumpFromRepairShed1); //到第一个修车棚里充气
myBicycle.expand(pumpFromRepairShed2); //若干天后,到第二个修车棚里充气2.关联关系的特征
对于两个相对独立的系统,当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时,这两个系统之间为关联关系。例如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司;再例如自行车和主人,每辆自行车属于特定的主人,每个主人有特定的自行车,图1-40显示了主人和自行车的关联关系。而充电电池和充电器之间就不存在固定的对应关系,同样自行车和打气筒之间也不存在固定的对应关系。
图1-40 主人和自行车的关联关系
Person类与Bicycle类之间存在关联关系,这意味着在Person类中需要定义一个Bicycle类型的成员变量。以下是Person类的定义:public class Person{
private Bicycle bicycle; //主人的自行车
public Bicycle getBicycle(){
return bicycle;
}
public void setBicycle(Bicycle bicycle){
this.bicycle=bicycle;
}
/** 骑自行车去上班 */
public void goToWork(){
bicycle.run();
}
}
在现时生活中,当你骑自行车去上班时,只要从家里推出自己的自行车就能上路了,不象给自行车打气那样,在需要打气时,还要四处去找修车棚。因此,在Person类的goToWork()方法中,调用自身的bicycle对象的run()方法。假如goToWork()方法采用以下的定义方式:/** 骑自行车去上班 */
public void goToWork(Bicycle bicycle){
bicycle.run();
}那就好比去上班前,还要先四处去借一辆自行车,然后才能去上班。
3.聚集关系的特征
当系统A被加入到系统B中,成为系统B的组成部分时,系统B和系统A之间为聚集关系。例如自行车和它的响铃、龙头、轮胎、钢圈以及刹车装置就是聚集关系,因为响铃是自行车的组成部分。而人和自行车不是聚集关系,因为人不是由自行车组成的,如果一定要研究人的组成,那么他应该由头、躯干和四肢等组成。由此可见,可以根据语义来区分关联关系和聚集关系。聚集关系和关联关系的区别还表现在以下方面:
(1) 对于具有关联关系的两个对象,多数情况下,两者有独立的生命周期。比如自行车和他的主人,当自行车不存在了,它的主人依然存在;反之亦然。但在个别情况下,一方会制约另一方的生命周期。比如客户和订单,当客户不存在,它的订单也就失去存在的意义。
(2) 对于具有聚集关系(尤其是强聚集关系)的两个对象,整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周期依赖于整体类的对象的生命周期,当整体消失,部分也就随之消失。比如小王的自行车被偷了,那么自行车的所有组件也不存在了,除非小王事先碰巧把一些可拆卸的组件(比如车铃和坐垫)拆了下来。
不过,在用程序代码来表示关联关系和聚集关系时,两者比较相似。图1-41为自行车Bicycle与响铃Bell的聚集关系。
图1-41 自行车和响铃的聚集关系以下例程1-6是Bicycle类的源程序。
例程1-6 Bicycle.java
public class Bicycle{
private Bell bell;
public Bell getBell(){
return bell;
}public void setBell(Bell bell){
this.bell=bell;
}/** 发出铃声 */
public void alert(){
bell.ring();
}
}
在Bicycle类中定义了Bell类型的成员变量,Bicycle类利用自身的bell成员变量来发出铃声,这和在Person类中定义了Bicycle类型的成员变量,Person类利用自身的bicycle成员变量去上班很相似。 -
2007-11-01
CICS/6000基础
CICS/6000与DCE
CICS/6000使用的DCE的服务包括:
1. RPC远程过程调用
2. Cell Directory Service(CDS) 单元目录服务
3. Security Service 安全服务
4. Threading Service 线程服务
单元目录服务(CDS)为网络命名提供方案,使得通过名字确定其他DCE服务的位置。当客户应用程序希望使用服务器应用程序服务时,可以通过名字查询CDS,以确定服务器的位置。
CDS名通常以/. ../形式开头,这就意味着DCE机器使用本地单元而不是远程单元。当配置CICS/6000时,生成一个目录/. ../cics. 当CICS启动后,在这个目录中签到。
CICS/6000使用DCE授权,提供对CICS和Encina相关服务器的高级安全访问。为访问CICS功能,身份必须属于预先定义的DCE组。这些组包括:
1 cics_admin 允许其完成CICS任务的维护工作
2 cics_user 允许作为CICS客户访问CICS
3 cics_region 所有的CICS用户都是其成员
4 cics_sfs 所有的SFS服务器都是其成员
5 cics_ppcgwy 所有的PPC服务器都是其成员
CICS/6000使用Encina OLTP ToolKit提供的服务程序。CICS/6000内部使用的服务程序有:
1 客户日志服务
2 XA数据库支持
3 交易管理
4 交易RPC
5 端到端执行
外部实用的服务程序有:
1 结构化文件服务器 SFS
2 端到端网关
-
2007-11-01
CICS系统管理简介
CICS 的有关的几个概念
1 事务处理监视器
事务处理由事务处理监视器控制。事务处理监视器完成协调联机事务处理所必需的所有功能。 在 CICS 中,由 CICS Region实现事务处理监视。CICS Region可以响应同时来自多个客户的请求,可以有效地提高事务处理的吞吐量。2 结构化文件服务器 (SFS)
SFS 是一个面向记录的文件系统,它在支持大量并行用户和可跨越多个磁盘的大文件时,提供事务完整性和基于日志的恢复。
SFS 能够提供数据处理与管理功能。数据处理功能提供访问和修改数据所必需的标准操作:读、插入、更新、删除、锁定、解锁等等。管理功能允许程序 查询和修改 SFS 文件和卷、复制和删除文件等等。SFS 使用 RPC 与其它服务器通信。3 区域(region)
CICS 区域处理一个或多个客户请求的事务。通常,区域经过访问数据库、完成一些商业逻辑,然后才答复客户。
CICS 区域维护并使用一个多线程的进程池,其中每个进程提供一个处理事务的完整环境,这样的进程称为应用程序服务器(AS)。
每个 CICS 区域协调它的应用程序服务器所需要的所有资源服务。例如,CICS 区域协调应用程序服务器的安全性,获得它们需要的数据与存储器并记录它们的事务。除了以上优点,多个 CICS 区域还可用来为分散工作负载提供一个分布式事务处理环境,提供事务处理的能力。
CICS 区域将许多服务分给其他更有能力做此工作的服务器,例如,CICS 区域可使用SFS 文件或 DB2 数据库来存储和管理用户数据。
CICS 区域作为一项 Windows NT 服务运行。CICS 区域包含了几个由监视器进程监视的内部进程。该监视器进程处理所有启动和关闭 CICS 区域的 Windows NT 服务请求。4 CICS中的数据类型
在CICS中,数据能以下列形式存储:
文件 -- 永久存储直到被明确删除的数据。
队列 -- 处理请求或将数据从一个任务或一个程序传递到另一个任务或程序的临时数据。队列能在 CICS区域的多个执行体上保留,并能表示永久数据。队列是顺序的。
关系数据库 -- 存储在一个特殊结构中,由 RDBMS 支配并使用结构化查询语言(SQL)命令访问的数据。
日志 -- 一组用来在发生故障后恢复数据更改的特殊用途的文件。
数据是一种可用于一个或多个服务器的全局资源。任何任务都可以读、写或删除数据,并能与其它任务共享数据。5 服务和子系统 (Subsystem)
在开放系统和 Windows NT 上,CICS 区域和 SFS 服务器作为一个特殊的程序类别运行。在 AIX 上,该类别即为“子系统”。子系统由系统资源控制器管理。在 Windows NT 上,该类别即为“服务”。服务由 Windows NT 服务控制管理器管理。
在其它开放系统平台上,并不存在作为操作系统一部分的子系统的概念, 由 CICS 模拟系统资源控制器的功能。
在开放系统和 Windows NT 上,作为服务或子系统运行的程序可并行运行。
在 Windows NT 上,控制面板“服务”应用程序显示了一列服务,其中包括 CICS 区域和 SFS 服务器。(注意:CICS 区域和 SFS 服务器不能由“服务”应用程序启动和停止。)6 远程过程调用(RPC)
DCE 支持的核心是 RPC。RPC 提供了分布式系统中两个进程间的一种网络透明通信 形式。进程使用 RPC 以完全相同的方式进行通信。l 日志
? 事件日志 (仅 Windows NT 平台上)
? 系统日志
l 两阶段提交
当要提交一个事务时,事务处理系统要确保所有在此项工作中涉及的可恢复服务器都提交它们的更新。如果一个或多个服务器不能这样做 (例如,与资源管理器的通信发生故障),那么所有服务都必须回滚。已提交的数据更改都是永久性的。
为了完成上述操作, 提交过程有两个阶段 (称为两阶段提交):
在第一阶段 (准备阶段),服务器协调程序要求每个参与者记录足够的工作信息,以使事务处理服务器能够提交或回滚。
在第二阶段 (提交阶段),服务器协调程序检查所有参与者已成功完成它们的更新。如果都已成功完成,那它就提交更新;否则,作回滚操作并异常终止事务。l CICS 的启动顺序
? DCE
RPC 精灵程序必须处于运行状态。如果在 DCE 单元中配置 CICS,那么 CDS 和安全性服务器以及服务软件必须也处于运行状态。
? 文件管理器
如果使用用于队列和文件管理的 SFS,那么当启动区域时它会自动启动。不过,如果使用 DB2 或远程 SFS,那么在启动区域前必须启动这些组件。
? 本地 SNA
如果一区域使用本地 SNA 支持,那么此时应该启动 SNA。
? PPC 网关服务器
如果区域使用 PPC 网关,那么 PPC 网关服务器必须区域启动以前启动。注: Encina PPC 网关服务器 在 Windows NT 上不可用。不过,可在一台有 PPC 网关服务器的机器例如 IBM RS/6000 上使用远程 PPC 网关服务器。
? CICS 区域
CICS 区域必须在以上各项都成功地启动之后,才能启动。
l CICS 的停止顺序
CICS 区域依赖于其它基本组件。因此,必须首先关闭区域,并在 CICS 区域完全关闭之后,才可以顺序关闭那些基本组件。关闭顺序应该为:
? CICS 区域
? PPC 网关服务器 (如果是处于运行状态)
? SFS
? DCE
l CICS 区域的启动方式
? 热启动(Auto):
如果CICS以前的运行正常终止时,CICS保留存储在瞬时数据队列和临时存储器队列中的任何数据。
如果CICS以前的运行异常终止时,例如一个立即关闭或一个硬件错误,CICS执行在热启动方式下任何必要的恢复处理,并保留在可恢复瞬时数据队列和临时存储器队列中的任何数据,但丢失存储在不可恢复队列中的数据。
而当 CICS 区域热启动时,不从永久资源库中装入运行资源库中,直接使用运行资源库运行。
对于资源 XAD ,即使是热启动,该类资源也是从永久资源库中装入。它仅仅在应急启动时才从运行资源库装入。
? 冷启动(Cold):
冷启动时,不进行尝试恢复任何以前正在运行的事务,并且丢失存储在瞬时数据队列和临时存储器队列中的任何数据。
一个新建的区域在创建后第一次启动时,它必须被冷启动以保证区域正确的初始化。
当 CICS 区域冷启动时,它将需要的资源定义从永久资源库中装入运行资源库中。
? 应急启动,如果区域以立即关机终止或异常终止。当 CICS 区域执行应急启动时, 不把永久数据库复制到运行时间数据库中,保留在可恢复瞬时队列和临时存储器队列中存储的任何数据,但丢弃存储在不可恢复队列中的数据。CICS 将执行在该方式下任何必要的恢复处理。
l CICS 区域的停止
? “Normal” - 正常停止:
正常停止过程将分为如下两个阶段来进行:
A. 在终止的第一停顿阶段
假设所有终端为活动的,所有 CICS 设施为可用的,那么 CICS 按如下方式运行:
2 允许正在运行的任务完成。
2 允许将要自动启动的任务完成。
2 CICS 运行完毕保存在 RD 中的阶段 1 程序列表中列出的任何用户编写的程序。
B.在终止的第二停顿阶段
在该阶段期间,终端已变为不活动的,CICS 将不再允许任何新的事务启动,当在阶段 2 程序列表中列出的最后一个程序运行结束时,第二停顿阶段结束。
CICS 然后执行下列任务:
2 CICS 把统计资料写至统计资料文件中。
2 CICS 关闭所有文件。
2 CICS 将用于随后自动启动的信息写至重新启动文件中。
2 CICS 停止运行。? “Force” - 强制(立即的)停止:
当请求 CICS 的强制(立即的)停止时,在以下方面与正常停止过程不同:
2 CICS 不等待用户任务完成。
2 CICS 不再运行任何在区域定义(RD) 中定义的停止程序列表中的程序。
2 CICS 不把信息写至重新启动文件。
? “Cancel” - 取消(异常强制)停止:
当请求一个取消(强制异常)停止CICS 时,CICS区域无需经历停止过程而被强迫停止。当且仅当系统在停止时间过长,或者在不能清除运行的任务以正常停止时,才能使用这种停止方式。
如果使用了一个取消(异常强制)停止,必须使用cicsnotify命令来释放任何还没有释放的资源,并删除region_lock文件。
l 永久资源库 (Permanent)
每台可启动 CICS 区域的机器都有一个永久资源库,存储了 CICS 区域的各项资源定义细节。例如,一个包含 CICS 区域名称和属性的区域定义。
永久资源定义必须在启动 CICS 区域之前创建。当 CICS 区域冷启动时,它将需要的资源定义从永久资源库中装入运行资源库中;而当 CICS 区域热启动时,不从永久资源库中装入运行资源库中,直接使用运行资源库运行。实际上,CICS 是根据运行资源库运行的。l 运行资源库 (Run-time)
每个 CICS 区域用一个可用来启动它的资源组列表定义。当 CICS 区域启动时, 将组中的资源定义作为运行资源定义装入 CICS 区域。运行资源定义存在于两个 CICS 区域实例中并在区域自动启动时装入。它们以与永久资源定义相同的方式在磁盘上维护。
运行时间定义独立于它们相关的永久资源定义操作。 例如,可以改变一个事务的运行时间属性而不影响它的永久资源定义。
当 CICS 区域运行时,它使用运行资源库来控制它的处理、跟踪它的资源更改并动态地添加新资源。 -
2007-10-18
理解oracle中的外连接
术语定义
保留行表: 外连接条件中不包含+号的表
注意:不包含+号的表是指在外连接条件中。 如下例所示:
where d.deptno(+)=10 无保留行表
where d.deptno(+)=70 无保留行表
where d.deptno=e.deptno(+) d 是保留行表表
where d.deptno(+)=e.deptno e 是保留行表表
where d.deptno=10 不考虑,普通的连接条件
where d.deptno(+)=e.deptno and e.deptno(+)=10 无保留行表 d和e均包含了+号
左外连接中左边的表。
右外连接中右边的表。
全外连接中全部的表。
替换 NULL 的表:
左外连接中右边的表
右外连接中左边的表
全外连接中全部的表
在全外连接中,两张表既可以保留行,也可以替换 NULL。
当不存在匹配的行时,替换 NULL 的表替换 NULL。如果连接操作中不存在匹配,任何在 SELECT 列中引用的替换 NULL 表的列都将替换为NULL。
外连接的处理
1 取出外连接的两个表: d,e 见图1,2
2 取出满足连接条件的所有行,加上保留行表中所有不满足连接条件的行,
不满足连接条件的行的组成:
保留行表中的列保留原值,替换 NULL 的表中的列都将包含 NULL。
3 几种特殊情况
a 见图3,4
where d.deptno(+)=10 无保留行表
where d.deptno(+)=70 无保留行表
b. 见图5,6
where d.deptno(+)=e.deptno and e.deptno(+)=10
<==>
where d.deptno=e.deptno and e.deptno=10
c. 见图7,8
where d.deptno(+)=e.deptno and d.deptno(+)=10
<==>
d right join e on (d.deptno=e.deptno and d.deptno=10)
d. 见图9,10
where d.deptno(+)=e.deptno and d.deptno=10
<==>
d right join e on d.deptno=e.deptno where d.deptno=10
附d 的 sql代码
select D.DEPTNO as ddeptno,
D.DNAME,
E.EMPNO,
E.DEPTNO,
E.ENAME,
e.deptno as edeptno
from scott.D d , scott. E e
where d.deptno(+)=e.deptno and d.deptno=10
select D.DEPTNO as ddeptno,
D.DNAME,
E.EMPNO,
E.DEPTNO,
E.ENAME,
e.deptno as edeptno
from scott.D d right join scott. E e
on d.deptno =e.deptno
where d.deptno=10
-
在描述JNDI,例如获得数据源时,JNDI地址有两种写法,例如同是 jdbc/testDS 数据源:
A: java:comp/env/jdbc/testDS
B: jdbc/testDS这两种写法,配置的方式也不尽相同,第一种方法应该算是一种利于程序移植或迁移的方法,它的实现与“映射”的概念相同,而B方法,则是一个硬引用。
java:comp/env 是环境命名上下文(environment naming context(ENC)),是在EJB规范1.1以后引入的,引入这个是为了解决原来JNDI查找所引起的冲突问题,也是为了提高EJB或者J2EE应用的移植性。
在J2EE中的引用常用的有:
JDBC 数据源引用在java:comp/env/jdbc 子上下文中声明
JMS 连接工厂在java:comp/env/jms 子上下文中声明
JavaMail 连接工厂在java:comp/env/mail 子上下文中声明
URL 连接工厂在 java:comp/env/url子上下文中声明可以通过下面的结构示意来发现这两种描述的不同之处:
A: java:comp/env/jdbc/testDS(虚地址) ------> 映射描述符 ------> jdbc/testDS (实际的地址)
B: jdbc/testDS (实际的地址)
从这种结构上来看,A的确是便于移植的。再来看一个例子:
假如你需要获取datasource,例如:dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/testDS");
那么在配置文件中进行资源映射时,在web.xml中,
<resource-ref>
<res-ref-name>jdbc/testDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
在相应的资源配置xml中(不同的应用服务器均不同,WSAD中,可以进行可视化的设置),
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/DBPool</res-ref-name>
<jndi-name>OraDataSource</jndi-name>
</resource-description>
</reference-descriptor>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/testDS只是用来和它作映射的,这样做的好处是为了提高可移植性,移植的时候只需要把配置文件改一下就可以,而应用程序可不用改动。假如你写了一个一般的应用程序,想直接通过JNDI来获取数据源,那么直接lookup(“mytest”)就可以了(假如服务器上的JNDI为mytest),用第一种写法反而会报错的。(没有使用J2EE应用服务器的情况下)
from Dekn







