Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1754128
  • 博文数量: 335
  • 博客积分: 4690
  • 博客等级: 上校
  • 技术积分: 4341
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-08 21:38
个人简介

无聊之人--除了技术,还是技术,你懂得

文章分类

全部博文(335)

文章存档

2016年(29)

2015年(18)

2014年(7)

2013年(86)

2012年(90)

2011年(105)

分类: 其他平台

2013-03-18 19:06:14

前面我们介绍了VTOC,VSAM,紧接着我们研究Z/OS下文件系统最重要的概念 catalog,说白了就是在主机环境下文件是如何定义,存储以及访问的,这一点同我们在平台端看到的还是有一些不同的。CATALOG的目的是为了便于文件的访问,使得你访问的时候,只需要知道DSN就能访问,至于具体的device,以及volume ser,都有catalog来帮你实现,对你就像是透明的一样,同时使得文件对应用程序是透明的,也便于管理。
本文主要对catalog进行的一个详细介绍。
首先介绍一下引入catalog的背景,这样理解起来会更好:
You want to access a dataset on volume VOL001. If you know the volume serial number you can simply code it in, either in your JCL code, or on an ISPF panel. The allocation request goes to the VTOC, where it finds the exact cylinder and head location of the dataset. The Volume Table Of Contents (VTOC) also contains physical information about the dataset, such as its record length and blocksize, to allow the fetching program to make sense of the data.
This is fine if you know which volume you want. A typical z/OS shop will have a thousand or so disk volumes available, and several thousand tapes. It will also run DFSMS, an automated data allocation product. When you allocate a new file, DFSMS selects the target volume for you, usually ignoring any preference you might have had. This can make if difficult to find a file later, so what you need is a way to record the location of every file on the system. That is, you need an ICF catalog system.
The VSAM Volume DataSet (VVDS) is an essential component of the ICF catalog structure. It contains physical information about VSAM datasets, and also DFSMS information about non-VSAM datasets. The VVDS can also be considered to be an extension or the Volume table of Contents or VTOC and has a one to one relationship with each volume. Every SMS managed volume and every non-SMS volume that contains VSAM files will contain one VSAM volume Dataset (VVDS).
catalogDSN的过程主要包括以下几步:
Building a Catalog
下面是建立catalog的具体步骤:
在所有的catalog中,master catalog是所有catalog的出发点,它是必须存在的,
Define the Master Catalog
The Master Catalog is the starting point for all file allocations. It contains dataset location entries for all the essential system datasets that start SYS1.** and must contain the ones used to IPL (or boot) the operating system. It will also contain other dataset location entries, depending on your installation setup. However, the master catalog should not contain location information for all datasets, system performance would be really dire if it did. It should really only contain what's needed for an IPL and nothing else. It should be RACF protected to ensure that only systems programmers and storage managers can update it. Everybody else should get read only access. 
Actually there is nothing special structurally about a master catalog, it is just a BCS. In fact a master catalog in one LPAR can be a user catalog in another LPAR. The master catalog is defined in SYS1.PARMLIB(LOADxx) and the definition will include the VOLSER that the catalog resides on. A simple way to find the name of the master catalog 
Define User catalogs
User catalogs contain location information for the majority of your data. User catalogs are defined using IDCAMS with a syntax that looks like
  

点击(此处)折叠或打开

  1. DEFINE USERCATALOG( -
  2.     catalog name and other cluster parms -
  3. ICFCATALOG -
  4.    DATA -
  5.     data parms -
  6.    INDEX -
  7.      index parms -
  8.     CATALOG(master.catalog.name)
Each User catalog is connected to the Master catalog using the IDCAMS 'import .. connect' command. User catalogs can be shared between LPARs, but if the LPARs have unique Master catalogs, then every User catalog must be connected to every Master catalog.
How many User catalogs are required? You basically need enough to spread the performance load, and also to spread the risk of catalog failure. More about this in the next section, about aliases.
If you want to delete a User catalog, use the IDCAMS command

点击(此处)折叠或打开

  1. DELETE USERCATALOG ( -
  2.    name -
  3.   RECOVER -
  4.  USERCATALOG
This physically deletes the catalog. but the RECOVER parameter keeps the aliases that pointed to that catalog intact in the Master catalog.
Define Aliases
The Master catalog contains a list of aliases which point to the correct User catalog. You do this with the IDCAMS command 'define alias {name} relate catalog {name}'. This is the point where you need to sit down and work out your catalog structure and naming standards. The 'alias' is the high level qualifier, or the bit of the dataset name before the first dot. (It is possible to set catalogs up with multi-level aliases, but I'm keeping this simple. I like it that way, its easier to fix when it breaks}.
If you want to define a new AXP alias you have two things to worry about. First, will your AXP alias be used heavily? If so, you don't want to put it into a User Catalog which is already busy. Second, a User catalog is a single point of failure. If AXP forms part of an application, then its best to keep it in a different catalog from other, independent applications. If the catalog fails, then you limit the impact to one application system. So in other words, you need enough user catalogs to separate out applications, and to keep busy aliases separate. However be sensible. If you have five hundred applications it would probably not be a good idea to have five hundred catalogs as you need to monitor and maintain them all. In this case, group applications together into sets that make sense in business and recovery terms and give each group its own catalog.
If you need to list out all the defined aliases that are defined in the master catalog use the IDCAMS command
 LISTCAT ALIAS CAT(master.catalog.name)
If you want to delete an alias use the DELETE ALIAS command. If you want to delete all the aliases that are defined to one user catalog, the easiest way is to use the EXPORT .. DISCONNECT command, followed by IMPORT .. CONNECT. DISCONNECT will delete all the aliases, but CONNECT does not re-define them. Before you do that, I'd suggest saving the output from a LISTCAT ALAIS command as above, just in case you need to put them back again.
catalog  Your  DSN
Finally, you add a dataset entry to the user catalog, which points to VOL001. That's a long winded way of saying that you catalog the dataset. This is normally done for you automatically when you allocate the file. Uncatalogued datasets can be defined using the IDCAMS DEFINE ... RECATALOG command.
For each dataset, the catalog entry contains the volume location, DFSMS data and the dataset type. The physical information about the dataset is held in the VTOC and the VVDS. Every volume (unless its non-SMS and contains no VSAM files) has a VVDS, which is always called SYS1.VVDS.Vvolser, so the relationships between volume and VVDS is 1:1. A volume can contain several catalogs, and typically, a volume will contain datasets which are catalogued in several catalogs, so the relationship between volume and catalog is n:n. There are no proscribed naming standards for catalogs, but a good one is catalog.** Since the introduction of hypervolumes it has been standard practice to allocate each catalog on its own, dedicated volume. This may not be necessary since PAV aliases were introduced, but it still seems to be a intuitively sensible thing to do.
下面我们针对上面操作中涉及的重点进行介绍:
Actually there is nothing special structurally about a master catalog, it is just a BCS.
catalog其实就是BCS,本质就是前面介绍的KSDS,

The BCS
? Is physically a VSAM KSDS
? Records have keys
? Limited to 123 extents
? Contains entries for all data sets, non-VSAM and VSAM, on tape or DASD
? Contents consist of associative information, volsers, and other information needed to locate a data set
?Data set attribute, extent, and statistic information is not in the BCS – it’s in the VVDS
而catalog的建立可以分为master catalog与user catalog,如下图所示:

而VVDS则是存储了卷上DSN的详细信息:
The VVDS
  Is physically a VSAM ESDS
  Records have component names, not keys
  Access is direct by RBA to a control interval
  Contains the BCS names for the data sets on the volume
  Record types are:
  VSAM Volume Record (VVR) for a VSAM component
  Type Z  for a primary record (DSNs, attributes, extents)
  Type Q  for a secondary record (DSNs, extents)
  Non-VSAM Record (NVR) for non-VSAM data sets
  Type N  record (DSNs)
  Various control records (VVCR, VVCN, VVCM)
VVDS Rules
? The name of the VVDS is:
SYS1.VVDS.Vvolser
? The size of the VVDS is your choice and should be at least 1
cylinder
? Implicitly allocated if you don’t allocate – the default size will be
TRK(10,10)
? Since z/OS 1.7 a system default can be set
? Default is not preserved across an IPL
? F CATALOG,VVDSSPACE(prim,sec)
?Space values specified are in tracks
关于VTOC的信息,我们正在前面的博客中已经介绍过,这里只给出简单点额介绍
Volume Table of Contents (VTOC)
A system data set which maintains extent and allocation
information for a volume
Used to find empty space for new allocations and to locate
non-VSAM data sets
Used to obtain information not kept in the VVDS for all
VSAM data sets and SMS managed non-VSAM data sets
?Data Set Control Blocks (DSCBs)
Free DSCB
DSN and 3 extent definitions
13 extent definitions
VTOC DSN definition
BCS ,VVDS,VTOC之间的关系如下:
BCS Relationships
For a VSAM component – the BCS points to the VVR in the
VVDS
For non-VSAM data sets – the BCS points to the VTOC
Format 1 (“F1”) DSCB
Even if they are SMS managed
上面给出就是我们的catalog信息,其实catalog的作用在我们的window下都已经被OS来实现,因此我们不需要去关注,但是在主机的情况下,我们需要单独使用工具IDCAMS来进行管理,其实最终的本质都是文件系统的管理。
这是关于文件系统的第三篇文章,还有一部分没有介绍就是ESDS,这个由于实践中用的比较少,后续有机会会补上,关于主机文件系统的介绍就告一段落,谢谢。
ref:





阅读(2594) | 评论(0) | 转发(0) |
0

上一篇:KSDS OF VSAM 详解

下一篇:VTSS-VSM简介

给主人留下些什么吧!~~