\n'); } function setFlash(){ var myFlshObj = document.myFlash; var photoAlbum=document.getElementById('photoAlbum'); if(photoAlbum&&myFlshObj){ var awidth=0; awidth=parseInt(photoAlbum.offsetWidth); if(awidth<260) myFlshObj.height='150px'; if(awidth>=260 && awidth<350) myFlshObj.height='240px'; if(awidth>=350 && awidth<370) myFlshObj.height='305px'; if(awidth>=370 && awidth<550) myFlshObj.height='320px'; if(awidth>=550 && awidth<730) myFlshObj.height='455px'; if(awidth>=730) myFlshObj.height='590px'; } } function setAlbumUrl(name){ albumTypename=name; setFlash(); myFlash_DoFSCommand(null,"test"); } function showLoginWindow(ev){ var obj = document.getElementById("pop-login"); if(document.all){ obj.style.top = ev.clientY +'px'; obj.style.left = ev.clientX - 272 +'px'; } else{ obj.style.top = ev.pageY +'px'; obj.style.left = ev.pageX - 272 +'px' } obj.style.display ="block"; document.getElementById("pop-user-name").focus(); } function hideLoginWindow(){ document.getElementById("pop-login").style.display ="none"; } var blogID=getBlogID(); var UserName = ""; if(blogID!=null){ var tmpUserName=blogID.split("."); UserName=tmpUserName[0]; } function resize(obj){ if(window.event.srcElement.tagName == 'A'){ return; } obj.parentNode.childNodes[1].style.display = obj.parentNode.childNodes[1].style.display=='none' ? 'block': 'none'; obj.parentNode.childNodes[2].style.display = obj.parentNode.childNodes[2].style.display=='none' ? 'block': 'none'; } function tab(event){ var evt = (document.all)?window.event:event; if(evt.keyCode == 9){ document.getElementById("pop-password").focus(); return false; } else{ return evt.keyCode; } } function tab1(event){ var evt = (document.all)?window.event:event; if(evt.keyCode == 9){ document.getElementById("save").focus(); return false; } else{ return evt.keyCode; } } function tabTrack(event) { var evt = (document.all)?window.event:event; if(evt.keyCode == 9){ document.getElementById("pop-password-track").focus(); return false; } else{ return evt.keyCode; } }
狼,站在北风中,嚎啸——北风狼
个人资料
日历
统计
统计中,请等候...
统计中,请等候...
日志
|
| |||
| |||
|
|
| |||
| |||
|
AS/400文件系统
任何操作系统最显而易见的部分就是文件系统。大多数操作系统把可由用户命名的对象叫做文件。
文件可以包含程序,数据或者其他任何用户希望包含的东西。操作系统提供创建,删除,读写和其他
管理文件的应用程序接口(APIs)。
大多数操作系统都有自己独特的文件类型。例如:UNIX系统有通常的文件,目录,也有特殊的块
文件和字符流文件。目录用于追踪文件的用途,同时也用于装载文件符号名所需要的信息。块文件和字
符流文件则用于模拟硬盘和终端设备。
无须惊讶,我们最初纳入OS/400的应用之一就是使OS/400能够存储其他操作系统上,例如: UNIX
之上的文件。在操作系统OS/400 V3R1上,我们引入了集成文件系统(IFS)的概念,它不仅创建了与传统
AS/400操作系统相兼容的体系结构,同时还创建了其他操作系统所需要的新结构。随着时间的流逝,
新的文件系统就诞生了! 截止到iSeries服务器发布,集成文件系统(IFS)已经可以支持十种文件系统
和三种服务器类型。
集成文件系统(IFS)是操作系统OS/400的一部分,它提供给用户和应用程序一个访问传统数据库
文件,库,文件夹,文档和传统上AS/400上的其他对象的兼容的体系结构。此外,集成文件系统(IFS)
还提供对PC和UNIX系统上使用的流输入/输出文件的支持。包含连续长字符数据的流文件对于
存储图象,声音信号,视频信号变得日益重要。集成文件系统(IFS)还提供对存储在本地iSeries
服务器上或远程别的类型服务器上的流文件的浏览功能。
为了管理这些文件,我们创建了一种新的层级的目录结构。这种层级的目录结构是通过类似PC
和UNIX上的指定目标的存储路径来访问该对象的。这种文件目录结构允许根据应用程序的要求通过
不同的文件系统或一般程序接口来处理面向记录的数据库文件,UNIX流文件。
支持不同的文件系统通过相同的程序接口来访问是集成文件系统(IFS)的独特功能。要了解如何
能做到这一点,我们首先来看一看最初是怎样在系统中使用这样的结构去查询对象,以及它是怎样
发展成现在的集成文件系统(IFS)的?
在S/38系统上,在数据库中查找一个对象是相当简单的:就象我们在第8章中所学习的,因为每
个对象都有一个名字,你只需要在库里搜寻这个名字就可以了。库提供了一种将对象组织成组并且
允许对象可由名字索引的方法。这种库结构一直为OS/400操作系统所沿用。
库(Library)
库是OS/400操作系统上的一种对象,是一种可以经由它找到其他OS/400对象的对象。库不象PC或
UNIX等操作系统上的多层目录结构,它是单级结构。让我们通过OS/400上对象的命名规则来阐述这种
单级结构。
要在OS/400上搜索一个对象,我们必须知道该对象的名称及所在的库(例如:库/对象),同时我们
还需要知道对象的类型,以次来唯一确定这个对象。两个或多个对象可以有相同的名称,但是它们必
须是不同类型的对象。换而言之,在同一个库里,可以有一个名称为SAM的程序和一个名称为SAM的数
据区域,但是不能在这个库里有两个名称为SAM的程序。同样的道理,一个对象能且只能存在于一个
库里。
除了一个库例外,任何库不能参照其他库,如果这样做的话就会违背库/对象这种单级结构。
因此,除了一个名为QSYS的库可以参照其他库之外,其他任何库都没有这个功能。少数几个特殊的
OS/400对象只能存放于QSYS库中,例如:存放用户权限信息的用户简要表(user profile),用于
输入/输出操作的输入/输出配置对象(I/O configuration object)。
在系统中,库列表是与作业想关联的,库列表告诉系统当查询一个对象时按照什么样的顺序去
执行查询任务。由此可见,库结构是相当简单的。
共享文件夹(Shared Folders)
共享文件夹的概念最早引进OS/400是为了支持Office/400的功能。S/36是一个相当好的办公系
统,许多与文件夹相关的概念就是由S/36发展来的,OS/400上的文件夹对象类型的引入就是为了支持
S/36上的办公功能。简而言之,集成的办公环境支持为办公对象提供了一个可以为办公产品包含数据
的文件系统。传统应用所用到的邮件,文档,程序和文件都可以包含在这个文件系统中。
文档库服务让用户视文件系统为包含文档库对象的电子文件柜。文件夹管理服务使用户可以在
文件夹中组织对象,并且文件夹可以包含其他文件夹,同时可以被交互地查询。
为了使PC有效地合并到办公环境中来的目标使得原来使用在S/36系统上的共享文件夹被广泛应用,
并后来被引入OS/400操作系统。因此,除了以上提及的传统的办公对象之外,共享文件夹也能够存放
象电子表格,曲线图,图象,PC程序和PC文件的流文件。
IBM多次增强了PC Support产品的功能,但是这个产品已经过时并且越来越不能满足客户机/服务
器应用,并且PC Support也不能支持当前客户所希望使用的所有PC操作系统,尽管它提供了运行DOS,
DOS增强版,OS/2等PC客户端的能力,但是显然地,它不能支持运行微软视窗操作系统的客户端,因此,
PC Support需要做大的变革。
IBM用新的叫做Cient Access的产品代替了PC Support,Cient Access提供了分布式客户机/服务
器应用的平台。为了支持一些新的客户端操作系统,OS/400的文件系统也作了相应的调整,例如:为
数据库应用所用到的库,PC文件所用到的文件夹,但是客户端需要更多的文件系统种类,这样,新
文件系统就应运而生了。
集成文件系统(IFS)的体系结构
最初,最大的挑战是如何构建能够支持所有的文件类型的单一的文件系统,后来设计了相互独立,
且并不兼容的多种文件系统,并将它们结合成一个体系结构之内。这样,最初设计文件系统所遭遇的
问题就轻易地解决了。
请注意,其实我们先前讨论的OS/400操作系统上的单层库结构实际上是PC操作系统使用的文件系
统的一个子集,虽然名称不同于PC的命名方式,但是结构却是相似的:在PC操作系统上的文件在
OS/400操作系统上称之为对象,在PC操作系统上的目录在OS/400操作系统上称之为库。与OS/400操作
系统不同的是,PC操作系统上的目录可以包含其他目录,称之为子目录。这样就使得PC操作系统上的
多层命名规则不同与OS/400操作系统的单层命名规则,例如,一个PC文件的全路径可以是:
DIR1DIR2...DIRnFILENAME, 可见,它是OS/400操作系统上的库/对象的单层命名规则的父集。
同样的,UNIX文件系统也是OS/400上库/对象结构的父集。请记住:一个OS/400的对象只能存在
于一个库中,也就是说,OS/400上到一个对象只有唯一的一条路径,但是,UNIX系统允许多条到达
同一对象的路径。
因此,使用类似UNIX文件系统的单一根目录结构就可以实现我们要把多种文件系统统一在一个
体系结构下的构想,同时所有其他的文件系统都位于这个根目录之下。命名规则就类似:
DIR1DIR2...DIRnFILENAME。
为了配合象Posix, XPG等基于UNIX系统的开放平台标准,我们增加了文件名和目录名的长度。
存放在集成文件系统中的对象名的存储方式我们称之为Unicode,这是一种国际标准,它支持多
种语言,包括许多国家都会用到的双字节字符集。所有RISC系统都能够支持在数据库中存储以
Unicode编码的文件。
RISC系统上,Unicode对数据库的支持技术的引入使得应用程序开发者能够使用业界跨平台的
通用数据格式,这就意味着,任何应用程序可以用通用的代码书写,并被全世界使用,也就是说,
不需要为某个双字节语言国家编写特殊的双字节程序的特殊版本。
请牢记,集成文件系统提供了访问数据的途径,但是数据格式必须与应用所要求的相兼容,或
者数据格式可以转换成与程序相兼容。OS/400可以处理iSeries内部编码EBCDIC与PC上的ASCII编码
之间的转换。
所有文件系统和集成文件系统中的文件都被视为OS/400上的对象。除此之外,任何文件系统都
支持相同类型的操作,这些操作都被定义在相应的文件系统的标准操作表中。每一个文件系统都拥有
自己独特的一套信息存储与信息交互的逻辑结构和规则,与别的文件系统可能不尽相同。通过使用
表的方法,无须改变现有的文件系统或文件系统上特定的操作就可以将新的 文件系统加到集成文件
系统中去。
集成文件系统视传统的库和文件夹为单独的文件系统。任何具备不同功能的其他系统也被视为
单独的文件系统,正是有了这样的结构,我们就有可能随着需求的增加,将新的文件系统不断纳入
集成文件系统中。
图11.1显示了集成文件系统所支持的十种不同的文件系统和三种文件服务器。在我们逐个浏览
每个文件系统之前,我们必须理解集成文件系统提供了所有文件系统的通用接口。

虚拟文件系统(VFS)接口
虚拟文件系统是集成文件系统中用来为所有文件系统提供通用接口的结构。虚拟文件系统是一种
面向对象的接口,它提供的对象叫做虚拟节点(vnode)。虚拟节点是一个抽象的对象,但是它代表了
存放在文件系统中的真实的对象,这样做的目的是让文件系统中定义的抽象的操作能够运行在实在的
对象上。
图11.1显示的逻辑的文件系统要处理文件系统中的对象,首先要取得代表该对象的虚拟节点,接
着,执行该虚拟节点上的相应的操作。由于逻辑的文件系统并不真正去访问实际的文件系统对象,所
以,不必知道真正的对象的物理影象以及位置。
因此,在任何时候,虚拟文件系统都代表着物理的文件系统。关心对象的物理影象和位置的物理
的文件系统并不知道从应用程序所看到的文件系统的逻辑组成。为了使之能工作,物理的文件系统必
须要提供虚拟节点和虚拟文件系统的操作接口。
由于这样的层级结构,应用程序使得物理的文件系统赋予逻辑文件系统以控制权,然后逻辑文件
系统找到应用程序需要的物理对象所代表的虚拟节点,并调用相应的虚拟节点操作来实现应用程序
所要求的动作。无论什么时候,逻辑文件系统要求一个基于虚拟节点的操作,它都不会知道物理文件
系统所要执行的操作。
我们之所以要使用虚拟文件系统接口,就是要将高层的逻辑文件系统和底层存储数据的物理空间
分开。这样分开之后,就可以在一台机器上安装多个物理文件系统,并使他们能够为应用程序透明地
访问。同时,它也提供了一个相对简单的实现增加新的物理文件系统的机制。
集成文件系统支持的文件系统
现在让我们来逐个讨论一下图11.1中描述的文件系统。目光敏锐的读者也许已经注意到,有一个
早期的文件系统已经从这张图表中消失了,它就是QLANSvr文件系统。这个文件系统中包含与OS/2
Warp服务器共享的文件。由于iSeries上已经不再支持OS/2 Warp服务器了,所以这个文件系统就从
iSeries上移走了。从上文的讨论中,我们知道,将来应用环境所需要的文件系统可以被添加进来,
同样的,不需要的可以被移走。
-- 根(Root)文件系统
根文件系统包含DOS和Windows文件系统的文件和目录,通过类似UNIX系统的层级结构来访问,并
且优化了流文件的输入和输出。
-- 开放系统(QOpenSys)文件系统
QOpenSys文件系统中存放的是基于UNIX的文件和目录,它完全与其他基于UNIX的开放系统标准相
兼容,例如:Posix, XPG.
-- 库(QSYS.LIB)文件系统
QSYS.LIB文件系统是原始的AS/400库结构,它包含OS/400的库和其他类型的OS/400对象。QSYS.LIB
文件系统提供给集成文件系统的用户一个利用层级结构访问这些对象的接口。利用QSYS.LIB文件系统
创建的对象完全可以从传统的非集成文件系统的OS/400界面去访问。QSYS.LIB文件系统支持源物理
文件/成员和用户空间(User Space)等数据对象的输入/输出操作,同时,还支持库,源物理文件/成员,
数据,用户空间的创建,以及库中大部分对象的删除,重命名,移动,拷贝,查询属性等操作都支持。
-- 文档库服务(QDLS)文件系统
QDLS文件系统支持从S/36系统上继承到OS/400系统上来的文件夹结构,它提供了访问文件夹和文档
的接口。 此外,它还支持以流文件存储的OS/400上的文件夹,文档库对象的数据。
-- OS/400文件服务器(QFileSvr.400)文件系统
QFileSvr.400文件系统提供访问远程iSeries服务器或AS/400服务器上的文件系统的接口。当用户
向对方文件系统提出文件服务请求时,QFileSvr.400文件系统可以作为客户端,与目标系统上的OS/400
文件服务器共同工作来完成实际的文件操作。
-- 用户自定义文件系统
用户自定义文件系统(UDFS)包含用户自己定义和自己管理的文件系统。UDFS存放于辅助存储池(ASP)
中。
-- 网络(NFS)文件系统
NFS文件系统提供用户访问远程网络文件系统数据和对象的接口。一个NFS服务器可以开放一个网络
文件系统,这样,NFS客户端就可以加载到该文件系统上。任何一个加载到iSeries服务器上的文件系统
都属于网络文件系统的范畴。
NFS首先由SUN MicroSystem公司为了在UNIX环境中访问分布式文件系统而创建的,从此,NFS协议
就成为了互联网的业界标准,现在许多平台都支持这种协议。OS/400 V3R7支持NFS V2版本;OS/400
V4R4支持文件超过2GB的NFS V3版本。 现在,最新的NFS版本是V4。
-- Windows NT服务器(QNTC)文件系统
QNTC文件系统包含本地或者远程运行Windows NT/2000的xSeries服务器访问的文件。它能够让iSeries
上的应用与Windows客户端使用相同的数据。我们将在第16章详细讨论xSeries的集成问题。
-- NetWare(QNetWare)文件系统
QNetWare文件系统包含本地或者远程运行Novell的xSeries服务器访问的文件。NetWare文件系统
可以被现存的文件系统动态地影射,同时,它还提供访问NetWare目录服务的对象和存放在流文件中的
数据的接口。
集成文件系统支持的服务器
图11.1中列出了集成文件系统所支持的服务器类型。我们简要地讨论一下在文件共享的网络中
使得iSeries既作为服务器端又作为客户端的UNIX服务器,Windows服务器和OS/400服务器。这些服
务器连同它们的文件系统使得iSeries服务器能够从本地或者远程支持应用程序的运行。
除了我们以上提到的三种服务器,集成文件系统还支持xSeries服务器(集成在iSeries内部或者
远程连接的)和iSeries分区上运行的Linux服务器。图11.1中只显示了运行Windows NT/2000的集成
xSeries服务器和运行Novell NetWare的xSeries服务器,QNTC文件系统和QNetWare文件系统还包含
了本地或者远程xSeries服务器上的文件。请注意,PC客户端直接与xSeries上的操作系统做交互,
而不使用集成文件系统的应用程序接口。第16章和第19章中我们将重点讨论xSeries服务器和Linux
服务器。
-- NFS服务器
NFS服务器和NFS文件系统使得在远程文件系统或目录加载到本地UNIX工作站,PC机或iSeries时,
iSeries服务器既可以作为服务器端又可以作为客户端。就象先前我们提到的,NFS文件系统提供
用户访问远程网络文件系统数据和对象的接口,作为NFS服务器端,iSeries可以导出一个网络文件
系统供NFS客户端来加载。NFS服务器可以从以下任何一个文件系统中将数据(如:文件,目录,库,
文件夹等)导出:root(/), QOpenSys, QSYS.LIB, QDLS, QOPT, UDFS。
因此,NFS服务器和NFS文件系统共同作用通过为远程终端导出本地文件系统和从远程服务器加载
导出文件来实现数据的分布式处理。客户端和服务器之间的通讯是通过远程过程调用(RPC)来实现的。
-- OS/400 NetServer
OS/400 NetServer能够让运行Windows的PC可以访问集成文件系统的目录和OS/400的输出队列,
前提是iSeries服务器和PC机上都配置了TCP/IP协议。PC用户通过Windows的网上邻居来访问共享信
息。对于连接到iSeries服务器的PC用户来说,集成文件系统就象一块包含目录和对象信息的硬盘。
PC用户可以通过Windows/NetWare中自代的文件共享功能或者Client Access Express程序来访问集成
文件系统的文件。
我们对iSeries Client Access的支持作了一些重大的改变。过去,Client Access系列产品对
网络驱动器和打印机的支持都是内含在产品中的,现在,这些产品被两个产品替代了:
iSeries Client Access Express for Windows(称为超级终端) 和 iSeries Access for Web。
原先,要使用Client Access for AS/400,首先要在AS/400和PC之间先建立一个连接,然后,
使用系统程序接口(SPI),通过在PC上映射网络驱动器或通用命名规则(UNC)来访问集成文件系统上
的目录或打开文件。
iSeries超级终端使用Windows操作系统自代的文件共享功能来实现与OS/400 NetServer的网络
文件和打印访问。通过使用iSeries超级终端,用户还可以使用Client Access系统程序借接口,通
过操作导航器(它是iSeries最主要的图形用户界面)来访问共享文件。在操作导航器中,可以对集成
文件系统之下的目录进行创建,重命名和删除。Client Access系统程序界面还支持超级终端在集成
文件系统上的拖拽功能,这对利用SSL的优点非常重要,系统程序界面支持SSL,但是OS/400 NetServer
不支持SSL。
-- OS/400远程文件系统
OS/400远程文件系统(RFS)使用户能够透明地访问远程iSeries或AS/400服务器上的文件系统(我会
简单解释一下为什么没有将它纳入图11.1中)。远程文件系统被作为目录加在QFileSvr.400文件系统
之下,当一个客户请求从QFileSvr.400文件系统下的子目录提交时,远程的RFS就会在远程处理这个
请求。由于QFileSvr.400在远程服务器上来处理客户请求,所以没有在图11.1中将RFS单独列出来。
QFileSvr.400文件系统是通过层级结构来访问的,它的第一层目录是远程iSeries或AS/400服务
器的名字。QFileSvr.400文件系统与RFS文件服务器共同作用来完成真正的文件操作。RFS提供了一种
在两台iSeries或AS/400服务器之间共享文件的简单而有效的方法。
集成文件系统增强功能
在前几版的OS/400操作系统中,集成文件系统的功能不断地被增强,下面的章节中,我们将介绍
其中几个新增的功能。
-- UNIX类APIs
操作系统的一个重要任务就是提供应用程序接口在文件系统上来创建,删除,读写等方法来管理
文件。与UNIX层级结构一样,集成文件系统中也增加了许多UNIX类的应用程序接口。
其中的一个例子就是通过UNIX类的应用程序接口来做数据转换。应用可以使用不同于文件存储时
的代码页来读取该文件,一个读取的API可以从文件存储空间将其读出并转换成应用程序所希望看到的
代码页,类似的,一个写入的API可以将应用程序提供的数据在存入系统之前将其改变成希望存储的
代码页。这种数据转换的功能是iSeries服务器独特的。除了这些APIs,OS/400 NetServer也可以根据
文件的扩展名来实现数据转换。
支持Unicode路径名的功能也是新增的。一个内部使用Unicode的应用程序可以调用使用Unicode
路径名的UNIX类API。 此外,还新增了代码转换功能,原来,集成文件系统只能实现单字节到单字节,
双字节到双字节的代码转换,现在,集成文件系统已经可以支持Unicode混合编码的应用程序之间的代
码转换,这是一种为复杂的转换机制。
-- 图形化访问界面
现在,既可以通过OS/400上的控制语言命令(这种命令行语言是从S/38系统上延续到OS/400上的)
来访问集成文件系统中的对象,也可以通过Client Access中的操作导航器来访问集成文件系统中的对象。
-- 线程安全性
集成文件系统中使用的API在访问文件系统中的对象时,都具备线程安全性。我们将在第13章中详细
讨论线程及线程安全性。现在,我们只需要知道,root,QOpenSys,QSYS.LIB,QOPT,QNTC和UDFS等文件
系统都具备线程安全性。
-- 支持DataLink
DataLink使得存储在数据库文件中的数据类型大大地扩展了。数据库中DataLink字段是用来保存本地
集成文件系统,远程集成文件系统,或者安装了IBM DataLink Manager的Windows/UNIX服务器文件系统
上非数据库文件的参照关系的。DataLink在字段中并不真正存放数据对象本身,而是存放了对象文件的
位置。DataLink指向的对象可以是任意的数据类型 -- 例如,文本文件,声音记录或是图象文件。
对DataLink的支持使得用户可以在ROOT文件系统中指定一个存放DataLink对象的目录。一旦一个目录
被指定为DataLink目录,那么,对该目录下所有对象的访问都要通过DataLink文件管理器(DLFM)。一旦一
个DataLink目录下的对象被标定为DataLink对象,那么,DLFM就会创建一个包含到该对象的路径的前缀表。
所有企图对DataLink对象的访问,删除,重命名等动作都会被DLFM截取,并通过检查对象存储路径和前缀
列表来防止对DataLink对象的删除和重命名。DataLink指定的路径保证了存储在集成文件系统中的关联
文件的参照完整性。
结论
集成文件系统是iSeries服务器其他应用程序的基础,它增强了OS/400现有的数据管理能力,也增强
了对新兴的应用环境的支持能力。在我们随后要学习的很多应用环境 -- 例如,Lotus Domino, Linux,
Unix, 和 Windows,都将使用到集成文件系统提供的功能。
又回来了!
在沉寂了很久之后,我决定还是回来这里吧!
虽然之前这里不是让我很满意,但目前看来这里还是个不错的选择!
因为搬家实在是一个很费心思的事情,想了想还是算了!
不知道以前的朋友还是不是在关注我的这个空间了,但是我希望他们能回来这里,因为我很想念我的朋友们!
最近几个月来一直在忙碌于我的新工作以及我的新朋友,所以一直都没有写什么东西了,所以觉得自己变得越来越没有思想了,记得我的一个老师讲过,写文字可以使自己变的有思想有内涵,所以我将继续写一些乱七八糟的文字。
有空常来吧,朋友们!