This Part describes how to configure an enterprise server so that I/O for CICS- or JCL-related files is handled by a Fileshare server. The major reason for doing this is that it provides transactional VSAM file access for CICS-related files.
This Part covers only stand-alone Fileshare servers. A stand-alone Fileshare server is one that you run separately from Enterprise Server, by running fs.exe. Enterprise Server's built-in Fileshare server is not recommended for this use.
This chapter is intended to help you get up and running quickly. After a brief overview and an outline of the main points of configuration, it walks you through a typical configuration. The chapter Using Fileshare - More Features gives brief introductions to other useful and important aspects. The chapter Fileshare - Further Details goes into more detail.
Fileshare is a client/server file handler, supplied as part of Micro Focus Server. When you configure an enterprise server to use Fileshare, you are making the enterprise server a Fileshare client, so that some or all file I/O requests coming from applications running in that enterprise server will be handled by a Fileshare server.
You can configure some or all files that are accessed from CICS applications to be accessed via Fileshare. You can also configure files accessed by JCL, and even the catalog itself, to be accessed via Fileshare, if you wish. However, the major benefit of Fileshare is when used with CICS.
Although its name implies file sharing, the primary reason for using Fileshare is to support transactional access to data files using the COMMIT and ROLLBACK verbs or EXEC CICS SYNCPOINT when using CICS. Without it, there is no transactional behavior in CICS. Fileshare also provides rollforward recovery to ensure the integrity of your files in the event of a system failure.
On an IBM mainframe, when a CICS application accesses a VSAM dataset, the access is transactional. This means that CICS, acting as a Transaction Manager (TM), ensures that the updates to the VSAM dataset are committed or rolled back as appropriate. The application can control the transaction boundaries with explicit EXEC CICS SYNCPOINT commands, and CICS implicitly controls the transaction at end of task.
In the Mainframe Transaction Option, CICS provides VSAM emulation but does not provide transactional access to these resources. Fileshare does provide such access. The Mainframe Transaction Option acts as the TM and uses Fileshare's Resource Manager (RM) to provide behavior compatible with mainframe CICS.
No changes to your program source are needed to take advantage of Fileshare. If a resource definition indicates that a resource uses Fileshare, the default configuration provides backward recovery for that resource. This means that if an application explicitly backs out updates to a VSAM dataset, or CICS rolls back an update because of an application failure, Fileshare ensures that the dataset is returned to a consistent state.
If a file is accessed only from JCL, not CICS, then there is no advantage in using Fileshare for it. However, if it is accessed by both, and you configure it to use Fileshare for the sake of transactional VSAM access, then Fileshare is used for all accesses to it, whether from CICS or JCL. The later chapter Using Fileshare - More Features describes how to handle potential conflicts between accesses from CICS and JCL.
You need to configure both the enterprise server and the Fileshare server:
Sections in this chapter cover these topics in detail. The final section is a walkthrough of a typical configuration.
This section briefly summarizes what you need to do. A later section walks you through a typical example.
You start the Fileshare server from a Net Express command prompt, in the directory where you want the files it manages to reside. We'll call this the Fileshare directory. When you later configure your enterprise server, you can specify subdirectories of this directory for particular files.
You start it using the command:
start fs /s fs-server-name
or, if you want tracing:
start fs /s fs-server-name /tr f
A Fileshare console window opens. If you specified /tr f, the trace is written to this window and also to a file called fsscreen.lst in your Fileshare directory. You should normally delete fsscreen.lst before starting a Fileshare server, or your new trace output will be concatenated to whatever is currently in the file, which can be confusing when trying to track down problems.
You can turn tracing on or off while Fileshare is running, by pressing F2.
You should not normally use tr f in production, as it has a detrimental effect on performance.
Be sure to start your Fileshare server before your enterprise server, so that the Fileshare server is available right from the start to service any I/O requests the enterprise server may send.
To close the Fileshare server, press Esc in the Fileshare console window. You would normally do this only after stopping your enterprise server.
You need to tell your enterprise server which files are to be accessed via the Fileshare server.
Remember that a dataset is represented by a physical file on disk, and although the enterprise server can create a default name for the physical file there are various places where you can override this default and specify a name of your own choosing. To specify that a file is to be accessed via Fileshare, you specify the path and filename of the physical file and include in the path the name of the Fileshare server to use.
Wherever you specify the Fileshare server, you precede its name with "$$". For example:
$$server1
You can configure an enterprise server so that all datasets are accessed via Fileshare.
In ES Admin, on the Edit page for the server, on the JES tab, include the name of the Fileshare server in the path for the Default Allocated Dataset Location. You then don't need to specify anything for individual datasets, unless you want to override this.
Changes made on this page are picked up when you next start the enterprise server.
You can configure an individual dataset to be accessed via Fileshare, or by a specific Fileshare server overriding the one specified in the Default Allocated Dataset Location.
Go to the FCT page for the file (in ESMAC, select Start L on the Resources dropdown list, then click FCT, then click Details by the file), and then:
(Because JCL does not need transactional VSAM access, the catalog page does not have an explicit Fileshare Server field as the FCT entry does. However, simply including the Fileshare server name in the path in the Physical File field does as well.)
Note that the FCT page has check boxes called Backward Recovery and Forward Recovery. These are for use with integrated Fileshare, and are not relevant to stand-alone Fileshare.
In a similar way, you can specify that an extrapartition transient data file is to be accessed via Fileshare, by naming a Fileshare server on the file's DCT page in ESMAC. Also, the SIT page in ESMAC has four fields where you can specify that temporary storage queues (recoverable and non-recoverable) and intrapartition transient data files (recoverable and non-recoverable) are to be accessed via Fileshare.
You can specify that an individual file created by JCL or IDCAMS is to be accessed via Fileshare, or by a specific Fileshare server overriding the one specified in the Default Allocated Dataset Location.
In the DD or DEFINE command that creates it, use the extension %PCDSN (see the chapter Extensions to JCL and IDCAMS) to specify a physical filename to override the default location - include the name of the Fileshare server in the path/filename you specify here.
You can configure an enterprise server so that the catalog itself is accessed via Fileshare.
In ES Admin, on the Edit page for the server, on the JES tab, include the name of the Fileshare server in the path for the System Catalog.
This also causes the spool files to be accessed via Fileshare.
Changes made on this page are picked up when you next start the enterprise server.
In the real world you would probably not put system files such as the catalog under the control of Fileshare, since accesses to these are managed by enterprise server and it would not bring any advantage, just the additional overhead of Fileshare communications.
The configuration you create in this walkthrough makes all I/O for applications running in your enterprise server go via a Fileshare server.
In this walkthrough, we'll assume your Fileshare server runs on the same machine as your enterprise server. We'll create a directory to use as the Fileshare directory. Within this, we'll create a subdirectory to contain the the user files created and accessed by applications.
start fs /s server1
This starts a Fileshare server named server1.
The Fileshare console window appears, as shown below.
Figure 23-1: Fileshare console window
If you have the ES Admin home page visible at this point, you may notice that an entry appears for SERVER1. This is because Fileshare is implemented using Micro Focus's Common Communications Interface (CCI), and a Fileshare server is an example of a CCI server. ES Admin shows CCI servers as well as enterprise servers. The current status is shown as Registered.
We will create a new enterprise server to use for this walkthrough. You could alternatively apply your changes to an existing enterprise server.
We next configure this enterprise server to send all I/O requests for all datasets accessed by applications running in it to the Fileshare server.
Select the checkbox Job Entry Subsystem enabled.
$$server1\datasets
casstart /rFSDEMO
Now that your Fileshare server server1 and your enterprise server FSDEMO are both running, we will run a simple JCL jobstream to verify that new datasets are created correctly and that everything is working.
Because you used the casstart command to start FSDEMO, you can submit the JCL from the Net Express command line. In your c:\fsdir directory, enter:
cassub -rFSDEMO -jc:\fsdir\iefbr14.jcl
If you had started FSDEMO via ES Admin, you would have had to submit the JCL using the JES Control page in ESMAC.
The job is parsed and then waits for a batch initiator to run it.
The JCL job runs.
Put a check mark by the "DMFBR14" line and click Display to display the details for the DMFBR14 jobstream, as follows:
You should see something similiar to the following. Note how the Physical File field is qualified using the Fileshare server name.
You should see the joblog displayed below. The PC filenames have now been resolved to be qualified by the Fileshare server name. ($$SERVER1).
Now click Back and then click Catalog to display the JES Catalog page. The click Details by the entry for the newly created dataset DMF.TEST.DSN.
You have now verified that everything is configured and working.
Copyright © 2006 Micro Focus (IP) Ltd. All rights reserved.