| Fileshare Server Messages | Fsview | |
NetWare:
There are two methods of running Fileshare on Novell networks:
Fileshare NLM in not included in the standard COBOL product. You must purchase it separately. This chapter describes how to run Fileshare NLM.
It is assumed that you are already familiar with Fileshare and have read and understood the general information on Fileshare in the chapter Fileshare.
The Fileshare NLM has the same interface and start-up options as the Fileshare Server on other operating systems. The Fileshare NLM runs on servers running NetWare Version 3.1n. The Fileshare NLM runs on servers running Netware Version 4.01 or later with a prerequisite of Novell's CLIB.NLM Version 4.01E or later. You also need console privileges to load the Fileshare NLM.
Invoke the Fileshare NLM by entering this command at the system console:
load fs [options]
See the section Fileshare Server Configuration in the chapter Fileshare.
The Fileshare Server defaults to running at the SUPERVISOR privilege level. This means that any user on the network that can connect to the Fileshare Server can read or write to any data files on the server. To install the Fileshare Server with a lower security level, specify a User ID when you invoke the Fileshare NLM.
To set the User ID security for the Fileshare NLM:
This option tells the Fileshare Server to use this ID. The Fileshare Server then prompts for a Password to use with this ID.
Example
load fs
with fs.cfg file containing the lines:
/s srvr /nu user1
This tells the Fileshare NLM to log onto the NetWare operating system
with the User ID of user1. The Fileshare Server then prompts
for the Password to use when performing this logon request.
Note: You can use Fileshare password security for additional security. However, since the Fileshare NLM is supplied as a single file, fs.nlm, it is not possible for user supplied security modules (FSSecLog and FSSecOpn) to replace those supplied with the Fileshare NLM system. Hence, the only additional security available on NetWare is the Fileshare password security.
If your application accesses data files using DOS format filenames (using drives and paths), you have to map these filenames to NetWare format filenames. You can do this using filename mapping in the database reference file to avoid having to make any changes to the application program when accessing files on NetWare.
Example
load fs /d dbase.ref /fs e: /af vol1: load fs /d dbase.ref /fs d: /af vol2:
This example invokes the Database Reference File Maintenance Utility and adds entries to the database reference file. The entries specify:
e: have the
string replaced with vol1:. For example, a filename e:\accounts\today.dat
is mapped to vol1:\accounts\today.dat.
d: have the
string replaced with vol2:. For example, a filename d:\accounts\tomorrow.dat
is mapped to vol2:\accounts\tomorrow.dat. This database reference file must be specified in the Fileshare Server configuration file when the Fileshare Server is invoked.
The Fileshare NLM automatically uses the CCIIPX communications protocol. The file cciipx.nlm is supplied for this purpose. The Fileshare NLM automatically loads this module if cciipx.nlm is on the NetWare server search path.
If the file is not on the search path, you need to load the cciipx.nlm module before you invoke the Fileshare Server. To do this enter this command at the system console prompt:
load [path]CCIIPX
The Fileshare Clients that must contact the Fileshare NLM need to be configured to use the CCIIPX communication protocol.
In a few environments (especially those using RIP network routing architectures) Fileshare NLM installations may not be visible to client applications. This problem shows itself by the client application appearing to hang for two minutes when trying to open a Fileshare file and then receiving file status 9/124 (communications error).
If this occurs, check that the configuration of the Fileshare system is correct. If it is, you must specify the exact network and node address of the NetWare Server that the Fileshare NLM is running on in your Fileshare Client configuration file. This address can be determined by executing the SLIST command (NetWare 3.x requester) or NLIST SERVER command (NetWare 4.x requester) on a networked workstation.
The output from SLIST and NLIST includes text similar to the following:
Known NetWare File Servers Network Node Address Status -------------------------- ------- -------------------
NETWARE-SERV1 [ 60194] [ 80]
If "NETWARE-SERV1" is the name of the server that the Fileshare NLM is running on, you should put an entry in the Fileshare Client configuration file that specifies the machine address and the Fileshare Server name that you specified when starting Fileshare NLM.
The entry takes the form of a line starting with the /ma option followed by the network and node address returned from SLIST or NLIST separated by a dot. Follow this text with the /s option and the Fileshare Server name which corresponds to this machine address.
Example
/ma 060194.80 /s fs-serv
where "fs-serv" is the server name you specified when starting the Fileshare NLM on the NetWare server "NETWARE-SERV1".
This is the only change you should have to make to your Fileshare Client configuration file.
Example of modifications to an existing Fileshare Client configuration file:
Original configuration file contents:
/cm cciipx /s fs-serv
Modified configuration file contents:
/cm cciipx /s fs-serv /ma 60194.80 /s fs-serv
The default amount of memory available to Fileshare NLM for dynamic allocation is 8Mb. The memory allocation is dependent on your application and Fileshare Server's configuration. It is affected by many variables including the number of Fileshare Client sessions, the number of data files open, the data file types and the number of updates performed in a transaction.
However, the memory allocation limit is configurable using the /mm option in the Fileshare Server configuration file (see Fileshare Server Configuration in the chapter Fileshare on how to use the /mm option).
If the Fileshare NLM reaches the limit of memory it can allocate, it will be shown by:
To configure the memory available on the NetWare server, see your NetWare documentation.
This section describes the algorithm for calculating the memory used by Fileshare NLM.
Approximately 300 kilobytes (K) of memory is required on loading Fileshare NLM, before any file operations are performed.
This is affected by the /m (record size) parameter. The default record size is 64K, but can be specified in Ks between 16 and 64 using the /m parameter. Reducing the /m parameter reduces the amount of memory dynamically allocated on start up, although it limits the size of data records that can be processed.
Use /m to tailor your Fileshare system to the maximum record size in your data files.
If a database reference file or password file is used, more memory is allocated on startup. The amount is dependent on the contents of these files, since they are stored in internal tables - a different table for each parameter.
The table sizes vary from parameter to parameter, as follows:
Parameter |
No. of entries per block (n) |
Approx block size (bytes) |
First block dynamically allocated |
|---|---|---|---|
| /fs | 7 | 2300 | Y |
| /f | 24 | 6750 | N |
| /af | 16 | 4400 | N |
| /u .. /pw | 29 | 2550 | N |
If an "N" appears in the final column, it means the memory required for the first block used to process entries of that parameter is included in the initial 300K used when loading Fileshare.
The amount of memory shown is allocated for the first occurrence of each parameter in the database reference file or password file. Then, when that parameter table is full (after n entries), another block of memory is allocated.
For example, the first 16 /af entries do not require memory to be allocated at startup, but on the 17th entry found approximately 4400 bytes of memory will be dynamically allocated.
This is a detailed description of the amount of memory dynamically allocated by Fileshare NLM when file operations are taking place.
Approximately 1150 bytes are allocated for every 15 client applications simultaneously connected to Fileshare.
Memory allocations vary for different file types. All values are approximate.
| Sequential: | open a file exclusively | 4950 bytes |
| open a file shareable (1st time) | 860 bytes | |
| subsequent opens to same file by separate clients | 420 bytes | |
| Relative: | open a file | 860 bytes |
| subsequent opens to same file | 420 bytes | |
| Indexed: | Very first file opened in run unit | 16400 bytes |
| open a file (1st time) | 860 bytes | |
| subsequent opens to same file | 420 bytes |
In addition to this:
Every record which is rewritten in a transaction generates a memory allocation. The amount of memory allocated is equal to the length of the rewritten record. Therefore, the memory allocated in a transaction equals the sum of the lengths of all rewritten records.
This memory is deallocated at the end of the transaction (when a COMMIT or ROLLBACK request is issued).
If you have a Fileshare NLM with 100 clients connected, all accessing the same 50 indexed files, with all 50 files having a "/f" entry in the database reference file.
| Loading Fileshare NLM | 300,000 | |
| 50 /f entries in the database reference file | 6750 * 2 | 13,500 |
| 100 client connections | 1150 * 7 | 8,050 |
| 1st indexed file open | 16,400 | |
| Other indexed file opens | 860 * 49 | 42,140 |
| Up to 127 simultaneous opens | 1,670 | |
| --------- | ||
| Approximate memory allocation (bytes) = | 381,760 |
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Fileshare Server Messages | Fsview | |