FUJITSU OSD-BC V11 Net Storage Guide User Guide

BCAM Configuration

From a BCAM viewpoint, only the following must be described regarding the above physics:

1. The connection of the BS2000 node and line
   Either an HNC in the case of a SU /390 or a channel adapter in the case of an SU x86 servers, which does not differentiate BCAM in the description (see below “Defining the line” and SHOW-BCAM-ENVIRONMENT OWN-IP-ADDRESS 192.168.152.24)

2. The processor on a node must be described with the address with which it must be reached from the BS2000. The BS2000 communication partner is the net client with the running bs2netsagent (PROCESSOR-NAME: LOCFCAP and IP address: 192.168.152.12) which controls access to the files stored on the NFS server (the addresses in the IP network of the NFS server and the NFS server itself are not known to BCAM).

3. Settings must be made for optimum use of the transport system LPDU Link-Layer Protocol Data Unit (determined by the device) TSDU Transport Service Data Unit (set for processor)

The following BCAM commands are used for description and can be saved in the SOF or a CALL-BCAM-COMMAND file to restart BCAM.

DEFINE NODE
DEFINE THE LINE

DEFINE PROCESSOR/ROUTE (AT THE NODE)

ACTIVATE LINE AND NODE The output of the BCAM objects, that have been created to describe this partial configuration, is via:

CONFIGURE REDUNDANCY
The net client (on HNC!) can be redundantly configured on SU /390. Make the BCAM configuration of the second HNC accordingly and define as redundant net client via SET-NET-CLIENT-ALTERNATE. (see below under “Utilization in BS2000: Mounting remote file systems” ).

BS2000 User Administration
The user and group numbers (USER-NUMBER and GROUP-NUMBER) must be entered in the user catalog of the pubset on which the files are cataloged so that users can save the files as node files and process them on Unix/Linux systems, or vice versa to access the BS2000 files created by these systems. The user and group numbers must be aligned with the UID and the GID of the corresponding Unix/Linux system users.
Enter via:

Net Server

The system administrator of the NFS server configures a share on the NFS server and defines the owner (user and group number) that is to receive the access permission to this share. These must match the numbers for the net client process that are configured for the HNC or X2000 respectively (see section below “User ID and group ID of the bs2netsagent process”).

The configuration of the share (file group) is via GUI with ETERNUS CS. Further mount options are configured here:

Read/write access, authorized hosts, etc.

Notes:

• Details about the configuration of your NFS server are in the appropriate
• For security reasons, the mount option no_root_squash should not be set. If access from the client side is via root, it would also access with root rights in the released file However, the root_squash mount option is used for access with the rights of the ID “nobody”.
• Secure mode: The standard sys (=specified user ID) is used as a secure mode for the authentication of a NFS connection.
• Under NFSv4, the net server requires a link to an LDAP directory
• The NFS server shares that are accessible for BS2000 can be output from BS2000 via LIST-NET-DIRECTORIES

Net Client

Configuration on the SE server:

On SE servers, the net client settings are installed via the graphic interface of the SE Manager. The SE Manager facilitates central, web-based management of the entire SE infrastructure and most of the peripherals used by the SE server units. The data network DANPU01 with uplink to the customer LAN is intended for the connection of net storage. Both HNCs and Server Units x86 (SU300) are preconfigured with a LAN connection to DANPU01 when the SE server is delivered.

The public data networks are configured in the SE Manager via Hardware -> IP Networks -> Data Network Public -> DANPU. The table “NetUnit Information” shows the units configured on the network.

The following figure shows the configuration of the DANPU01 network of an SE server with redundant NetUnit, 2 HNCs and one SU300:

In the designation of the port names with the unit name (HNC1, HNC2, Su1SE2) as prefix, SP stands for “Slot n” “Port m”.
Configure Net-Storage via Hardware -> Server/Units -> (SE ) -> (HNC or SU300) -> Management, Folder -> Net-Storage.

Changes in the menus can be made having clicked on the pen symbol

Attention: Changes to the settings lead to a reset and restart of the Net-Client. This can lead to data loss during ongoing I/O. Changes should therefore only be made if no shares of a Net server (NAS) are mounted from BS2000.

Access :
The user ID and group ID are set via which the net client jobs are processed on the net server. They are the owner IDs of the share to be mounted on the net server and must be agreed with the net server system administrator. The default-value 0 should not be used for data protection reasons.

Configuration of NFSv4 domain
LDAP is only necessary if NFSv4 is in use and node files are to be stored which are to be accessed by external systems. The corresponding users must be in the LDAP server directory. Information about the LDAP server configuration is at the end of this section.

Net-Storage connection properties and add connection:

The following defines the PCI connections via which Net-Storage can be reached, whether a dynamic address should be assigned (check DHCP), or whether a static address should be entered (“Add IP address”).

On an HNC, the PCI port “Slot 2” “Port 1” is already preconfigured on the first public data network DANPU01 (DAta Net PUblic 01) when the SE server is delivered.

Procedure:
First, the PCI port must be added to DANPU01 via the button “Add connection ”:

If the IP address is to be assigned dynamically, it is sufficient to tick DHCPv4 or DHCPv6 with the pencil symbol for the now displayed connection “NETSTOR01”.

Net-Storage connection addresses:

Via the button “Add IP address” a static IP address can be entered:

If the net server is not in the same network as HNC or X2000, a router must also be defined. This is done via the tab “Routing & DNS”.

In an SE server with redundant NetUnit and second HNC, a Net-Storage connection should also be set up on the HNC2 (also on slot 2, port 1) for reasons of high availability

Example SU300:

An SU300 is preconfigured at the factory with slot 1 port 1 on the first public data network DANPU01. The following figure shows the net storage configuration of an SU300 with dynamically assigned IPv4 address.

Further details about the configuration of net client are in the current manual “Operate and Manage SE series Business Servers”.

Configure LDAP Server for Node Files with NFSv4

In order to ensure that access to node files – functions when using NFSv4-, an additional attribute “NFSv4Name” is compulsory in an LDAP POSIX account, in which the UID number is entered. The POSIX group can also be extended by the attribute “NFSv4Name”, but this is currently not compulsory

The attribute NFSv4Name comprises the user name and the NFSv4 domain user@nfsv4domain.

An entry in an LDAP directory could be as follows: “NFSv4Name: hugo@localdomain”. If not available, the LDAP scheme must be extended with the attribute NFSv4Name. The attribute definition of NFSv4Name is below:

The LDAP server must be configured so that the net server and the net client have read access to the LDAP directory.

The two following object classes must be entered. The object class NFSv4RemotePerson contains the NFSv4Name, uidNumber and gidNumber

The NFSv4Name attribute guarantees a one-to-one linking between the NFSv4 domain and the uidNumber of a local user. Below is a short example for an entry “hugo” in an LDAP directory:

Further Information

If a firewall is between net client and net server, note that the ports 2049 and 111 (RPC) for NFS must be opened for TCP and UDP. A change in the standard port 2049 is currently not planned.

During maintenance work (e.g. software update or new installation) and configuration changes with bs2netsConf, make sure that Net-Storage (which is operated via the respective net client) is disconnected beforehand from all connected BS2000 systems via the BS2000 command UMOUNT-NET-STORAGE.

Usage in BS2000 – Brief Overview

Having implemented the above configuration steps, Net-Storage can now be used in BS2000. Proceed as follows (operand values of the commands in the examples correspond to the examples in figures 2 and 3):

Mount the Remote File System
The remote file system is mounted via MOUNT-NET-STORAGE. The mount is initiated in the net client

SHOW-NET-STORAGE provides an overview of the mounted shares and, if necessary, any existing Net-Storage volumes.

A redundant net client can be added as follows:

If the net client fails, there is an automatic switchover to the alternative net-client.

Creating Net-Storage Volumes
Net-Storage volumes are created on the mounted Net-Storage via ADD-NET- STORAGE-VOLUME. The Net-Storage volume is permanently assigned to one subset.

A volume with the name ABC@00 is assigned to the pubset ABC. This is implemented by creating a directory with the name ABC@00 under the share /bs2data1 of the NFS server with the IP address 172.17.67.120. The administration files .FSL and .BS2FSCAT are created in this directory. An administration entry for the Net-Storage volume is created on the pubset ABC .

Instead of the standard name derived from the pubset name, the system administrator can assign any volume name for the Net-Storage volume. Several Net-Storage volumes can be defined for a pubset. The volume names must be unique in the system; if there is already a private disk with the same VSN, the access to the Net-Storage volume is preferred by the system.

SHOW-PUBSET-NET-STORAGE displays the Net-Storage volumes assigned to a pubset (this command can also be used by non-privileged users). Volume types of the NETVOL type are displayed as “not supported” (NO SUP) by systems lower than BS2000 V21.

Further hints:

Net-Storage can be assigned to both SF- and SM-Pubset, however not to a Home- PVS. The assignment of the Net-Storage volumes to a pubset is retained beyond EXPORT-/IMPORT-PUBSET and shutdown/startup. Net-Storage volumes can also be assigned to shared pubsets. The creation of the volumes needs to be done at the master system; the slave systems gain access to the newly created volume by entering the same statement ADD-NET-STORAGE-VOLUME. This is only necessary in the context of creation of the Net-Storage-Volume, to  allocate the volume by NDM. Later after shutdown/startup or EXPORT-/IMPORT-PUBSET respectively the allocation is done automatically by the system. After a system restart, make sure that MOUNT-NET-STORAGE is only executed after BCAM has been started and the subsystem ONETSTOR has been loaded. It is sensible – before importing a pubset (IMPORT-PUBSET) which has been assigned to the Net-Storage volume, to make it available in the system via MOUNT-NET-STORAGE. This ensures that its data is immediately available after IMPORT-PUBSET.

Create, Import and Process Files on Net-Storage

*Create BS2000 files**

If several Net-Storage volumes exist for a pubset, the volume (in this example volume NET001) can be specified as follows

This syntax applies equally to BS2000 OSD/BC V11 and BS2000 V21 – regardless of the NETSTOR or NETVOL volume type!

Create *NODE-FILE    files for interoperability with open systems (as of OSD V10)

• or short:
• respectively:

From now on, the file can be accessed via its path names. The storage location of the file is completely transparent for the application.

With the SHOW-FILE-ATTRIBUTE command, the user can determine the storage location of the file, e.g:

The user can already tell from the letter “n” between the file size specification and the CATID that the file is on Net-Storage. The example shows that the file is on the Net-Storage volume with the VSN NET001; it is a NETVOL volume type.

BS2000 saves node files in user-specific directories within Net-Storage volumes (see the example in figure 3: directories of users HUGO or FRITZ). BS2000 creates a user-specific directory the first time a node file is created for a user and automatically sets the required ACLs for access. Open systems can also create files in these directories.

Import of node files that were created by open systems into BS2000 catalogs.

If files were created by open systems in user specific directories, these files need to be imported into the BS2000 catalogs TSOSCAT and BS2FSCAT before they can be processed by BS2000

From BS2000 OSD/BC V11 the user can specify, if a node file should be catalogued as PAM or SAM file:

To specify FILE-STRUCTURE = *SAM is recommended, if the file should be processed as a text.

And vice versa, node files can be removed from the BS2000 catalogs via EXPORT- NODE-FILE (see EXPORT-FILE) without deleting them in the user-specific directory on Net-Storage. LIST-NODE-FILES is used to obtain information about the files (which can be imported) in the user-specific directories of a Net- Storage volume. Only files with names that meet the BS2000 file name conventions are output.

Export and Import of Net-Storage-Volumes

Net-Storage volumes can be separated (exported) from a pubset and imported to another pubset.

• Detaching a volume:
• Reattaching a volume to a pubset:

In the case of volumes of the NETSTOR type, the catalog entries for the files in the Net-Storage volume must then be imported manually using IMPORT-FILE

In the case of volumes of the NETVOL type, this is done automatically within the framework of the ADD-NET-STORAGE-VOLUME. If there are file name conflicts because files with the same name already exist, a corresponding error message is output and the command must be entered again. When importing a volume of the NETSTOR type under BS2000 V21, the volume can be converted into a volume of the NETVOL type with IMPORT =YES(CONVERT=YES). The volume can then no longer be accessed from systems lower than BS2000 V21. Also, the conversion cannot be reversed. For further details, especially when using mirror disks, please refer to the Introduction to Systems Administration and the DVS Introduction manuals.

File Processing

BS2000 supports the processing of node files by means of the access methods PAM (from OSD V10) and SAM (from OSD V11).

PAM node file processing

PAM node files are non-structured data, i.e. NK-PAM files from the BS2000 viewpoint. They can be read/write accessed via the UPAM access method. A node file can be any size up to a maximum of 4TB, i.e. in contrast to BS2000 disks there is no restriction to a multiple number of PAM blocks. This is already guaranteed with the previous PAM macros. The UPAM call to write is, for example:

i.e. with LEN=STD or STD,n    a multiple number of standard blocks of 2048 bytes is transferred; LEN=length transfers data of the specified length for node files

Example:

In this example the file on the NAS after CLOSE has a size of 2048 + 50 = 2098 bytes.

In order to write the exact file size of a BS2000 files, a new field was introduced in the catalog entry: the Last Byte Pointer (LBP) – analog to Last Page Pointer (=Highest-Used-Page) which points to the last valid page of a file – and the LBP points to the last valid byte of the last logical block. (A logical block has the size BLKSIZE=(STD,n), i.e. consists of n PAM pages (n*2048 Byte)). The value of the LBP can be determined via the macro FSTAT (field: OUTALBP). It is always supplied with node files. With PAM files on public space the LBP is only supplied if the caller sets the flag LBP_required with OPEN in P1FCB (support of this interface as of BS2000 OSD/BC V10 KP2/15).

If the application reads the file as far as end-of-file with LEN=(STD,x), it always receives complete PAM blocks – both with files on disk as well as on Net-Storage or as node files. The area of validity in the last logical block is displayed with the LBP. If the application reads the file with LEN=, it receives the data in the specified length.

As node files can also be processed by open systems, the properties of these files in the BS2000 catalog are outdated in certain circumstances. Any necessary update of values such as file size, LPP (=Highest-Used-Page), LBP and CHANGE-DATE occur as part of OPEN processing which is why the updated values are not available to the application until after OPEN. Updates can also be made outside OPEN/CLOSE via IMPORT-NODE-FILE REPLACE=*NODE-FILE-UPDATE.

Further details concerning the introduction of the last byte pointer can be found under: http://docs.ts.fujitsu.com/dl.aspx?id=22aafa65-9393-4a28-95fd- 4959fc6aa77d

SAM node file processing

Access method SAM:

There are two key differences between the processing of node files using the SAM access method and the processing of SAM files in the traditional public space – which in practice can mostly be neglected, these are specifically:

1. Whereas SAM records within SAM files in the public space may automatically contain any type of data, including binary, SAM node files are primarily intended for the purposes of text processing; when transferring logical SAM blocks, the net-client removes the characteristic SAM related structural information such as the BLKCTRL field and length fields and executes a code conversion from EBCDIC into either ASCII or ISO character sets. This is generally not possible where any binary content is concerned – at least not without any loss of information.
2. All SAM files stored on a traditional disc will be read from within the same block/record structure where they were previously written. In the file’s description, the user may make a note of the retrieval addresses for each of the records allowing them to access these at a later point in

It may further be added to the description of SAM node files that the SAM method of access, processes information in a block-oriented manner. However, in transferring the data to the NAS, the net-client removes the BLKCTRL field and length fields, so that the data is stored in a byte stream as would generally be the case for open systems. The individualized records are separated using a line feed (LF, x‘0A‘). The mapping of which record number was written to which block number was governed for the duration of the writing process between OPEN and CLOSE. That is to say, the application can be pointed back (SETL) to a block that has already been written to and subsequently overwritten. Furthermore, it is not mandatory to write a complete block, but may rather, as previously be closed with the macro RELSE; a following record (PUT) shall then appear in the next SAM block. This record will in any case be attached, without a gap, to the previous one within the NAS file system. After closing and then re-reading the file upon opening, the net-client prepares the data for SAM; standard SAM blocks are once more created from the byte stream of the Unix file and sent to the BS2000; by utilizing the BLKCTRL field and records, including fields indicating record length, the data is once again converted into the specified EBCDIC code. However, the original structure cannot be recreated. This means that only the sequence of the records may be guaranteed: individual records within the same block as well as record numbers cannot be read as they were written. In this way, retrieval addresses are as a rule no longer valid following a CLOSE and a re-OPEN.

In order to prevent any inadvertent processing of SAM files as node files through the use of legacy applications – which are dependent upon full compatibility in terms of retrieval addresses – a new flag SAM_NODE_FILE_ENABLE

(FCB+B9(+6): ID1SNFEN) has been introduced which the caller must implement ahead of the OPEN process within the FCB associated with the file.

An application that sets this bit signals to the operating system that it can both process SAM node files and also recognize their characteristics.

In its processing of SAM node files, BS2000 is supported by the following components:

• EDTU from V17.0D20
• SHOW-FILE from V17.1B30
• LMS/LMSCONV V3.5B
• openFT from V12.1A
• CRTE from V11.0A
• SYSFILE of OSD V11
• HSMS/ARCHIVE V11.0A

The user creates a node file as described in 3.3 and will then be able to process the file using either the aforementioned program or one they have written themselves.

As previously described when processing PAM node files, the SAM node files of systems in the outside world may be changed, e.g. extended or overwritten. The file properties FILESIZE, LPP and CHANGE-DATE are updated within the context of OPEN and are only then made available to the caller as current.

The largest SAM node file size that may be processed is 32GB. Having said that, the size of file that can be processed is limited by the number of logical SAM blocks that are required to allow it to be processed by BS2000. This limit is set at 16,777,216 blocks. Should more blocks be required, the OPEN will be rejected. The specific max. file size will for this reason depend in individual cases upon the length of records used as well as what fill capacity may be achieved within the SAM blocks. Based on this and depending upon the length of the records to be processed, the max. file size will be between 13 and 32GB.

In the case of an IMPORT-NODE-FILE, the logical block size (BLKSIZE) will be set at STD,16 so that large records may also be processed without issue (32k). The opposite also applies, where SAM node files are created in BS2000, the use of larger blocks is recommended (BLKSIZE=(STD,16)).

Code conversion

The user can in the case of SAM node files specify by file, a character set for the data on the NAS – the Net-Coded Character-Set or NETCCS. The net- client then performs the conversion from the file’s specified CCS into the NETCCS. In order to simplify the system administrator process for the user of setting up and selecting the character sets, the below procedure was introduced:

Similar to the Class-2-Parameter HOSTCODE as well as the CCSN of a user, as of OSD V11, both a Class-2-Parameter NETCODE as well as a NETCCSN will be introduced to the user entry. When creating a new user, the NETCCSN is selected from the CLASS2OPT NETCODE and deployed in the user entry, just as has been common practice to date for the CCSN. The CLASS2OPT NETCODE, or rather the NETCCSN within the user entry, controls which NETCCS the SAM node file will contain as standard at the point it is created:

NETCCSN| resulting file property/conversion: NETCCS of a file in CREATE-FILE
---|---
*ISO| Depending on the CCS of the file, a standard conversion is performed from EBCDIC to ISO8859x; within this context:

EDF03IRV, EDF03DRV, EDF04IRV and EDF04DRV -> ISO88591 EDF04x -> ISO8859x with x = 1,2,..,9,F

Even where a user specifies a 7-bit character set as the CCS, internally, an 8-Bit code table will be used. That is to say, in place of CCS EDF03IRV, EDF041 will be adopted and instead of

EDF03DRV, EDF04DRV will be utilized.

*NO-CONV| No conversion will be performed, i.e. NETCCS = CCS.