... the message "Local file is inconsistent" is output.
This may be because
a binary file was inadvertently transferred as a text file (Use the -b option!)
a text file contains records that are too long (Use the -r option!)
... the message "Remote system not available" is output?
This may be because
the partner address specified in the partner list, TNS or hosts entry is not correct. For BS2000 interconnections, you should check whether a BCMAP entry for $FJAM was made with the port number 1100 on the BS2000 partner (this is automatically created as of openFT V9.0 for BS2000 system).
the asynchronous openFT server has not started on the partner system.
a firewall in the partner system is blocking connections.
Please note that ftping is only intended for internal use and does not represent a guaranteed interface.
... the local system cannot be reached from the partner systems?
The following potential error sources should be examined:
Is the asynchronous openFT server started?
Does the local address match the default settings
(ftmodo -openft=@s) or has it been changed?If you use TNS on a Windows system:
Was an RFC1006 entry with TSEL $FJAM made for the local address?
Was port number 1100 assigned to the local application $FJAM? Port number 102 should basically never be used, since this could result in collisions with other application packets.
Was port number 1100 addressed in the partner system? In BS2000 systems, openFT automatically generates a BCMAP. For this to be successful, no old BCMAP entries may be present.
Is the openFT application released on the firewall?
... the message "Local system unknown in remote system" is output?
This means that your partner system does not accept your local system as a partner. In this case, you should check the following on the partner system:
Are dynamic partners connected and is there no or no suitable entry in the partner list for your local system?
Possible solutions:
Enter your local system in the partner list on the partner system or
Check the partner list entry in the remote system to determine, for example, whether the sent instance identification matches the entered instance identification, or
Permit dynamic partners.
Does partner address checking fail for your local system?
Check the settings for the operating parameters Identification and Processor on the local system.
... the message "Remote system xy unknown" is output?
This may be because
you must change the partner list entry, the TNS entry or the entry in the hosts file for the partner system,
a TNS entry is being used even though the use of TNS has been deactivated,
dynamic partners have been deactivated and the partner is not entered in the partner list.
... the BS2000 system cannot be accessed
If your local system in BS2000 is unknown, enter the command ADD-FT-PARTNER in BS2000.
If you receive the message “Remote system not available”, check whether one of the following reasons is the cause:
Resource bottleneck in the remote system
Remote FT system is not started
BCIN is missing
no network connection (for a TCP/IP connection, check the connection with the command ping, for example)
Name server entry is missing or is incorrect
... the name of the partner is missing in the log records
Enter the partner in the partner list, in the DNS, in the hosts file (/etc/hosts on Unix systems) or in the TNS.
... the logging function cannot be called, i.e. the logging file is no longer readable or is inconsistent
Possible reasons are:
System crash while log records are being written.
File system full while writing the logging file.
In Unix systems: kill on the openFT process while log records are being written.
The only remedy here is to terminate openFT (ftstop) and delete the log file.
You can determine the full path name of the log file in question using the command ftshwl -llf -plf=0, providing that the log file has not been changed since the problem occurred.
On Windows systems you can, for instance, use the Windows Explorer in order to delete the log file.
This means that you lose all log records in the affected file.
The explicit creation of an empty log file is not reasonable because an inconsistent log file remains due to missing header information.
To prevent space problems, you should
regularly change the log file (ftmodo -lf=c),
back up old log files on another computer or storage medium
and then delete the old offline log files on the openFT computer.
Alternatively: Activate the automatic deletion of log records (ftmodo, options -ld, -lda, -ldd and -ldt).
... access to the admission set and admission profile file causes errors or if this file is defective
The possible reasons are:
Manual access to sysfsa.dat and/or sysfsa.idx. These files are located in the respective openFT instance directory under config.
Unix system:
The path name of these files is as follows with the standard instance:
/var/openFT/std/config/sysfsa.dat
and
/var/openFT/std/config/sysfsa.idx
System crash with sysfsa.* open
In Unix systems, kill of openFT process with sysfsa.* open
In Unix systems, file system full on ISAM access
In Unix systems in cases 2 and 3 and 4, ISAM generally leaves an unusable index file.
Possible solutions:
Attempt to export/import:
Use ftexpe to export the data to a backup file.
Then shut down the openFT server with ftstop, delete sysfts.dat and sysfsa.idx and restart openFT with ftstart. Import the data from the backup file using ftimpe.Try to repair the ISAM index file with dcheck.
Example valid for the standard instance on Unix systems:
/opt/openFT/bin/ftbin/dcheck -b /var/openFT/std/config/sysfsaExample valid for the standard instance on Windows 10 systems:
dcheck -b "C:\ProgramData\Fujitsu TechnologySolutions\openFT\var\std\config\sysfsa"It may be necessary to delete the index file explicitly:
If the data file sysfsa.dat is empty then no data is lost. As a result, both ISAM files can be deleted with openFT stopped and can then be initialized before ftstart by using the ftshwa command.
If the data file already contains modifications to the admission sets and/or profiles then you should enter the following commands:
Unix system:
cd /var/openFT/std/config ftstop mv sysfsa.dat sav.sysfsa.dat && rm sysfsa.idx ftshwa >/dev/null rm sysfsa.dat && mv sav.sysfsa.dat sysfsa.dat /opt/openFT/bin/ftbin/dcheck -b sysfsa ftstart
Windows system:
cd C:\ProgramData\Fujitsu Technology Solutions\var\std\config ftstop move sysfsa.dat sav.sysfsa.dat del sysfsa.idx ftshwa del sysfsa.dat move sav.sysfsa.dat sysfsa.dat dcheck -b sysfsa ftstart
Explanation:
If sysfsa.idx is defective, it must be recreated. To do this, you must first back up the sysfsa.dat file that you want to create. You then use ftshwa to create a new sysfsa.dat file which you immediately delete and replace with the backed up sysfsa.dat file. The resulting file pair can now be re-used.
If this attempt also fails, you must delete the admission set and admission profile and make new entries to ensure a consistent state.
... You are not given a free transport connection for an ncopy request
On Windows systems this may occur with a connection to a non-TCP/IP network (e.g. X.25). Check the configuration settings for the corresponding transport system.
Check the partner address in the partner entry or in the partner list.
If you are working with TNS: check your TNS entries and check whether TNS use and operation with CMX are activated (in the case of ftshwo, the value YES must be displayed for USE TNS and USE CMX; otherwise activate TNS use and operation with CMX with ftmodo -tns=y -cmx-y.).
Check the address settings in the operating parameters.
... the openFT message “Remote transfer admission invalid” appears
For reasons of data security, this message does not differentiate between the various possible reasons for the rejection on the initiator side. This information is only available via the openFT logging of the responder system.
... requests still remain in the “WAIT” state?
Check whether the asynchronous openFT server is started in the local system
Check whether the openFT or asynchronous openFT server is started in the remote system
Using ftshwr -l, you can obtain further information on the cause.
.. in Unix systems, deleting a request in the openFT Explorer takes an unusually long time (about 1 minute)
This may mean
that a request was issued to send a mail when the request to be deleted is finished
and that the mail function of the Unix system takes about 1 minute to send a mail due to a configuration problem.
Solution:
Do not ask for a mail to be sent when the request is finished, i.e. specify the -m=n option for the ft command (or omit -m because -m is default as of V10.0). Requests that are started in the openFT Explorer never require a mail to be sent when finished.
... in Linux systems, the left mouse button does not function as desired in the openFT Explorer
This may be due to the fact that the function of the NumLock key was set differently on generation with Xfree and KDE (in larger SuSE Linux systems).
This causes problems if the NumLock key functions as an Alt Lock key: a click then becomes an Alt-click and a double-click becomes an Alt-double-click.
The administrator can overcome this problem by toggling the NumLock key. It may also be possible to set the Numlock functionality in the BIOS. The xmodmap command can be used to check and modify the keyboard allocation.
... on a Windows Terminal Server or Windows Server, the message "Can't create termination event (error x). Command aborted." is output when a user executes an openFT command.
This means that the openFT command cannot be executed due to missing user privileges. The problem might occur on Windows Terminal Server or Windows Server if the privilege to "Create global objects" is not granted to the "Users" group. The System Administrator must therefore grant the privilege "Create global objects" to the "Users" group to solve the problem.
... in Windows systems, the openFT service only starts when the system is rebooted, but cannot be started manually although the user has the necessary administrator rights?
In this case you will receive an error message from Windows with number 0xC0000022 regarding a failed initialization. This happens when a path with a network drive or UNC name or a path containing spaces has been entered in the PATH system environment variable before the openFT installation path. If the service starts automatically when the system is booted, then these entries are not active yet and the service will start normally. They will then be activated later on, but SYSTEM will not be able to access them because it does not have the proper rights.
Solution:
Clean up the path.
... in Windows systems, initialization errors occur in user32.dll or kernel32.dll when follow-up processing is started?
Cause:
The system environment variable PATH contains path inaccessible UNC paths/network drives.
Solution:
Clean up the path and use only local accessible paths.
Performance note
If you use the TNS during operation with CMX (ftmodo -tns=y), you should set the RFC1006 protocol for TNS entries, since the RFC1006 protocol is far more efficient than communicating via LANINET. In BS2000 systems, you should work without BCMAP entries. If you nevertheless need BCMAP entries then the following applies: If the PTSEL-I entry exists, RFC1006 is used.
In the case of operation with CMX, the RFC1006 protocol is always used.