1         const修饰指针名称，指针指向的地址不可变，但地址的内容可变，也可直接操作地址改变其内容。

例：

#include <stdio.h>

int main()

{

    char c='!';

    char d='w';

    char* const charPtr = &c;

    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;

          return 0;

}

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 端到端网关

 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 区域运行时，它使用运行资源库来控制它的处理、跟踪它的资源更改并动态地添加新资源。

     保留行表： 外连接条件中不包含+号的表

     注意：不包含+号的表是指在外连接条件中。 如下例所示：

        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

这两种写法，配置的方式也不尽相同，第一种方法应该算是一种利于程序移植或迁移的方法，它的实现与“映射”的概念相同，而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