Connectivity

Tools

openFT operation

FTAM protocol behaviour of FT

Workarounds for Interworking

Local FT behaviour using FTAM

Hidden Functions

X.25 configuration of BinTec Routers

The BinTec Routers X1000 II, X1200 II, X2100, X2300/i/is/s, X2404, X2250, X4000 Series or X8500 (see http://www.funkwerk-ec.com) can be used to set up a connection for openFT from any system supporting TCP/IP to a partner system over X.25 or X.25 over ISDN. TCP/IP is supported by openFT on many platforms like Windows, Linux, Solaris, HP-UX, IBM AIX, BS2000/OSD, z/OS etc. The documents which can be downloaded here describe the configuration of the BinTec X1000 II and X4300 router with the aid of an example. There are also sample configuration files (.cf) that can be loaded as a basic configuration in the corresponding router for further modifications.

Back to content

Command Execution Tool

openFT for Windows handles requests in processes that are started as services and are therefore optimally integrated into the operating system. Services are independent of interactively logged-on users since they run in a separate logon session of their own and also have their own runtime environment. This makes it possible for openFT to process requests for different users simultaneously and also perform follow-up processing for these users. However, because these user-specific follow-up processes run in a logon session of their own, they cannot simply be operated interactively by each user concerned, although this is sometimes desired by the user. To allow interactive operation, a tool has been created for openFT customers that allows applications to be started from within the follow-up processing in the interactive logon session of the user.
.

The tool is not included as standard in openFT versions up to and including V8.1, but it is available for download here. After downloading, the two executable files ft_cexsv.exe and ft_cexcl.exe must be copied into directory ...\openFT\bin. The tool will be included with openFT for Windows versions as of V10 and will be installed automatically. For a more detailed description see the documentation that comes with the tool.

Back to content

Start problem of the openFT server under Windows operating system

The TCP ports up to 1023 are called the well known ports and are assigned to specific applications. In the Windows operating system the ports starting with 1024 can be used by applications to listen for incoming calls and are also dynamically assigned by Windows for outgoing calls. If an outgoing TCP connection is established the next free port greater than 1023 will be used. The first connection gets port 1024, the next 1025 and so on until the maximum value is reached. Then the operating system starts again with the lowest available port.

An application like the openFT Server wants to listen for incoming calls, but can not reserve a certain port greater than 1023 for its private use. Therefore a resource conflict with other applications which also want to listen on the same port 1100 used by the openFT server might occur. An additional problem is caused by the Windows operating system due to its behaviour to use the ports greater than 1023 for dynamic port allocation for outgoing calls, although there is an extra range for such dynamically allocated ports in a much higher port region, which would not conflict with the port 1100 used by openFT.

During reboot a lot of processes are started and TCP connections are established and closed. That means the ports beginning with 1024 are used for this purposes. It might be possible that when the openFT service starts and tries to bind to port 1100 it might already be used by another server application or by an outgoing connection. Because a port cannot be shared by multiple applications, openFT can not bind to port 1100 and therefore the openFT server fails to start.

It might also be possible that the openFT server could not be started during reboot but can be started afterwards without any problems. Such situations are caused by an existing outgoing connection on port 1100 when the openFT server was started during reboot. After some time the connection on port 1100 is disconnected and the port 1100 is free for the openFT server.

The command "netstat -a -n" can be used to check if the port 1100 is already in use by another application. The option -n should be used in the netstat command to display the ports with its numerical number rather than its logical names, which can be assigned to a port in the etc/services file.

There also exists a great and easy to use tool named TCPView, which can be downloaded free of charge from http://www.sysinternals.com. TCPView can be used to monitor the currently used TCP ports and to identify the application that uses a specific port. TCPView should be configured to display the ports with its numerical values rather than its logical names.

Back to content

Application Entity Title

The Application Entity Title can be used for the addressing of OSI applications. It is a parameter in ACSE (ISO 8650), consisting of APTitle, AEQualifier, AP invocation id, and AE invocation id. The invocation ID's are not used in concrete FTAM projects (as far as we know). The APTitle can be used in two formats: an object identifier, and an arbitrary (ANY) format. The optional AEQualifier can be an integer or an ANY parameter. FT only supports the object identifier resp. integer format.

Behaviour in FT Version 5.2
In the initiator role, FT sends the NIL APTitle (1.3.9999.1.7) as calling and called APTitle. FT as a responder expects an arbitrary calling/called APTitle, and generates a responding NIL APTitle.

Behaviour in FT Version 6 (on UNIX and Windows platforms) As an initiator, FT can issue a called AP Title with an optional AE Qualifier. The AP Title can contain up to 10 integer components. This can be specified as an extension of the "partner name" in the commands ncopy, ft, ftshw, ftmod, and ftdel. For example, partner.(1.2.250.1.999.1.1.1..5) replacing partner will issue a called AP Title 1.2.250.1.999.1.1.1 and a called AE Qualifier 5.

By default, FT Version 6 doesn't issue an AP title. An option enables that FT sends the "NIL AP-Title" as calling AP Title, and as called AP Title - provided that none has been specified as partner name extension - but it does not issue an AE Qualifier. The option can be switched on and off by the commands:
fta -hf -ae=y and
fta -hf -ae=n
For interworking with FT Version 5.2 and with other partners expecting an Application Entity Title, the option -ae=y must be set.

As a responder, FT reflects the incoming called AP Title and the called AE Qualifier as responding AP Title resp. AE Qualifier, if -ae=n is set. If ae=y is set, the responder returns the "NIL AP-Title" as responding AP Title. The incoming calling AP Title is ignored.

Behaviour in openFT Version 7 (UNIX and Windows platforms)
The default behaviour is the issuing of NIL APTitles like in Version 5.2. The switch -ae=y|n and the partner name extension are the same as in Version 6. For FT version V7.0A20 on Windows platforms resp. V7.0A30 on UNIX platforms and later, it is possible to modify the calling resp. responding AE title, too. Define a REG_SZ value CALLINGAET in the registry key (for Windows platforms)
HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\openFT\CurrentVersion
resp. an environment variable CALLINGAET (for UNIX platforms), and set it to your AP title in the form nn.nn. ... nn (3 to 10 numeric strings separated by ".": the same syntax as that one inside the parentheses of the partner extension mentioned above).
This setting is valid for all commands, servers, and services started afterwards, and it will set the calling AE Title in A_ASSOCIATE request on initiator side, and the responding AE Title in A_ASSOCIATE response on responder side. As long as defined, it overrides the effect of -ae=y|n except for the called AP Title.

Back to content

Recovery and Restart

Kinds of recovery and dependencies on session functional units
ISO 8571 doesn't use the term Class-x-recovery. In the following, Class-x-recovery is meant to be the same as recovery from Class-x-errors. The FTAM parameter FTAM Quality Of Service indicates the maximum recovery facility proposed resp. negotiated for a connection.

The FTAM protocol (ISO 8571) supports three ways of recovery:
The mightiest way is the Class-III-recovery which can be applied in any case, even if one of the partner systems crash (establishing a new FTAM connection during recovery). Class-I- and Class-II-errors can be processed as Class-III-errors, thus recovery from all recoverable errors is possible.
Class-II-recovery keeps the FTAM connection, but closes and reopens the files to be transferred.
Class-I-recovery even keeps the files open, only repositioning to the last negotiated checkpoint on recovery. It is also called "restart", and it is supported in the "restart functional unit".
For class-I-recovery Minor Synchronize and Resynchronize Session functional units are required, but for the other kinds of recovery Minor Synchronize is sufficient (although the protocol handling is somewhat different if the Resynchronize FU exists, too). This is the requirement specified in the FTAM standard ISO 8571.

Transparency of Recovery Proceedings
It depends on the point of view what the question means "a temporary transport connection loss should be transparent to the application". In an enterprise file transfer like FT, the interface of an application is like "do the transfer of the file xxxx and tell me when it is finished". In this case, all three kinds of recovery processings are invisible to the application. In the ISO 8571 protocol, the application calls an F_INITIALIZE, an F_SELECT, and so on. At this application level, n o n e of the recovery processings are completely invisible, because the user and the underlying "External File Service" must share the access to the transfer file in any way. Compared with the other kinds of recovery, the restart (Class-I) hides the greatest part of recovery proceedings.

Recovery implementations in FT
For synchronous transfers, openFT doesn't support any recovery. For asynchronous transfers, openFT supports Class-III-Recovery, and it can be negotiated down to Class-II-Recovery. Class-I-Recovery (Restart) is not supported. The decision not to support Restart is based on the following facts:

  • it cannot be applied when the FTAM connection goes down, whereas class-III-recovery can be applied also for a simple loss of transport connection,
  • the time interval between loss and re-establishing a transport connection blocks an FTAM connection (which is a precious resource in an enterprise file transfer),
  • The class-I recovery specific protocol investigations would be much larger than those of class-II and class-III, and there are still a lot of severe problems in the class-I recovery protocol definitions itself.

Back to content

Future File Size

FT sends the parameter "future file size" in F_CREATE request when it is initiator and the sender of a file. If FT is initiator and receiver, it sends an F_READ_ATTRIBUTE request to interrogate the "current file size" of the file to be received. This file size is used to enable an optimal primary allocation for the receiving file (currently only for FT mainframe implementations), and to check whether there is enough space available for this file (for FT mainframe implementations, and for FT version V7.0 and later)

The basis of future file size for the file to be created is the number of bytes stored in the real catalog entry of the file to be sent from Windows 95/NT resp. UNIX. Also, if interrogated by the partner, this real catalog entry is the basis of "current file size".

For simple binary files (ncopy/ft -b, with string significance "not significant"), this number of bytes is exactly the real number of bytes of the file. For text files with variable lengths, the interpretation of file size is not so clear. The real catalog entry contains the total number of bytes including the line delimiters (1 per record in UNIX, 2 per record in WINDOWS). For GRAPHIC and GENERAL strings FT adds escape sequences selecting the G0 and G1 character sets to each string. These escape sequences must not be added to the string length (see the definition of the Document Type simple text in FTAM part 2), thus they must not be added in the evaluation of future file size. Provided that only the bytes in the virtual file without any headers, tags, length fields and CRLF's are encountered (the most evident way to specify a virtual file size), the file length in the real catalog can only be greater than the FTAM file size (but never less), and thus the value of future file size should be no problem.
There is one exception: the size of a GRAPHIC or VISIBLE string file containing TAB characters may grow because the TAB characters are expanded into sequences of space characters.

ISO8571/2 describes three possible behaviours of an FTAM instance when the size of a receiving file grows beyond "future file size":

  • extend the file without a warning, increasing future file size
  • extend the file with a warning, increasing future file size
  • indicate an error, not increasing future file size

The interworking between openFT-FTAM and ICL hosts fails because of future file size when FT is initiator and sender of a file. If future file size is not sent (for example if the sending file is stdin), the transfer to an ICL host succeeds. Therefore an option will be provided to omit future file size in F_CREATE request: in the registry key (for Windows NT/2000 and Windows 95/98)
HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\openFT\CurrentVersion
a registry value NOFUFILESIZE of type REG_SZ can be specified. On FT for UNIX systems, you can specify NOFUFILESIZE as an environment variable. The specification must be done before starting the servers/services for asynchronous file transfer requests, resp. before issuing synchronous file transfer requests. NOFUFILESIZE can take the following values:

1 future file size is suppressed for all partners
0 future file size is not suppressed
prefix future file size is suppressed for all those partners with partner names starting with prefix.

This workaround is relevant if FT is initiator and sender of a file, and an ICL host is responder. It is available on FT Version V7.0A20 (for Windows systems) and V7.0A30 (for UNIX systems).

Back to content

NORTEL: Workaround for NorTel partners

The NorTel workaround in openFT-FTAM covers the following requirements specific to the NorTel implementation of the FTAM protocol:

  • The ASN.1 syntax "FTAM-FADU" must be proposed in the connection establishment even if it is not needed
  • The "simple binary" syntax must always be proposed
  • The "simple text" syntax must not be proposed (thus text files cannot be transferred to/from NorTel switches)

On FT for Windows, the NorTel workaround can be switched on by creating a registry value named FTAMNORTEL of type REG_SZ under
HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\openFT\CurrentVersion.
On FT for UNIX systems, it can be switched on by specifying an environment variable FTAMNORTEL. FTAMNORTEL can take the following values:

1 the workaround is valid for all partners
0 means that the workaround is switched off
prefix means that the workaround is switched on for all those partners with partner names starting with prefix.

This workaround is relevant if FT is initiator and NorTel is responder. It is available on FT Version 7 and the latest update of Version 6 for UNIX and Windows systems.

Starting from V8 FT releases in the year 2003, an additional function for NorTel partners will be provided. The abstract syntax name and the document type name of NBS.9 directories exist in two variants:

  • the current form (provided in all FT versions, and in most of the FTAM implementations)
    iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-as2(2)
    iso identified-organization oiw(14) ftamsig(5) document-type(5) file-directory(9)
  • the old form (not provided by older FT versions)
    iso identified-organization icd(9999) organization-code(1) abstract-syntax(2) nbs-as2(2)
    iso identified-organization icd(9999) organization-code(1) document-type(5) file-directory(9)

Alternatively to those FTAMNORTEL values given above (which use the current NBS.9 document type form), one of the following values can be specified:

2 the workaround is valid for all partners, and the old NBS.9 document type form is used.
1prefix the workaround is switched on for all those partners with partner names starting with prefix.
2prefix the workaround is switched on for all those partners with partner names starting with prefix.
For those partners, the old NBS.9 document type form is used.

As a responder, FT understands both NBS.9 forms provided that the initiator specifies only one form in P_CONNECT request resp. F_INITIALIZE request.

Back to content

ERICSSON: Concurrency Control

FT doesn't support Concurrency Control in the FTAM protocol. Thus, the behaviour of concurrent accesses to a file is platform dependent, and it cannot be changed by a concurrency control parameter.

If FT receives a concurrency control parameter...
The behaviour of FT as a responding system receiving concurrency control parameters is that an informative diagnostic is created, but the file transfer resp. management action is continued. The informative diagnostic tells that concurrency control is not supported.

An interworking problem with ERICSSON partners
Ericsson sends a concurrency control parameter without having negotiated the Storage Attribute Group. This request is rejected by FT versions up to V7.0A10 (Windows) resp. V7.0A20 (UNIX platforms), because:

  • ISO8571, Part2, 13.9 (page 16), Current concurrency control "...is established on the select" (and create, because the creation implicitely selects) "action or on the open action." (at the end of the paragraph)
  • ISO8571, Part 2, 14.2 (p. 16/17) You can see that the current concurrency control attribute belongs to the Storage group.
  • ISO8571, Part 3, 13.8, Concurrency control, also found in the Technical Corrigendum 1 of part 3: "This parameter is used to set the current concurrency control activity attribute." (end of paragraph)
  • ISO8571, Part 3, 14.1.2.13, Attribute Groups "The requested attribute group parameter negotiates the set of optional file attribute groups to be a v a i l a b l e on the application association."

Workaround: Versions V7.0A20 (Windows) and V7.0A30 (UNIX) and later will ignore the absence of the Storage attribute group when a concurrency control parameter is recognized.

Back to content

ERICSSON, CoCoNet: Minimize Access Requests

In some cases, FT as an initiator wants to negotiate more than one type of "access request". Some FTAM partners reject a connection proposing distinct combinations of access requests (for example READ + READ-ATTRIBUTE).
As a workaround, the access requests can be minimized by specifying an environment variable FTAMMINACQ before issuing file transfer requests. The minimizing of access requests is also very useful when files are protected by different passwords for different types of access requests, because in the FT commands only one file or management password can be specified.
Also, if a file creation but no deletion is permitted for distinct files or users, this option may be useful in conjunction with "write-mode = NEW" (ncopy/ft -n).
FTAMMINACQ can take the following values:

1 access requests are minimized for all partners
not def. access requests are not minimized
prefix access requests are minimized for all those partners with partner names starting with prefix.

The access requests FT is proposing are:

type of request without with minimizing
Receive file (ncopy/ft) READ+READ-ATT READ
Receive and delete file (ncopy/ft) READ+DEL+READ-ATT READ+DELETE
Send a file, NEW (ncopy/ft -n) REPLACE(+DELETE)* REPLACE
Send a file, OVERWRITE (ncopy/ft -o) REPLACE+DELETE REPLACE(+DELETE)*
Send a file, EXTEND (ncopy/ft -e) EXTEND EXTEND
Read file attributes (ftshw) READ-ATTRIBUTE READ-ATTRIBUTE
Read file directory (ftshw -d) READ READ
Change attributes (ftmod) CHANGE-ATTRIBUTE CHANGE-ATTRIBUTE
Delete file (ftdel) DELETE DELETE

The minimizing of access requests works in the most recent updates of FT Version 6, and in all FT versions 7 and later for Windows and UNIX platforms. A side effect of the minimized access requests on receiving a file is that the free disk space cannot be checked at the beginning of the transfer, and that the progress information works without displaying the estimated end time of the transfer.

* In the most recent releases of FT V8 and later, access request DELETE is no longer used for the sending of a file with Write Mode NEW, and it can be switched off when a file is sent using Write Mode OVERWRITE.

Starting from the most recent V8 releases, FTAMMINACQ also affects the Permitted Actions on creating a remote file. Permitted Actions are set to:
without minimizing: READ, REPLACE, EXTEND, ERASE, READ-ATTRIBUTE, CHANGE-ATTRIBUTE, DELETE, TRAVERSAL
with minimizing: READ, REPLACE, EXTEND, READ-ATTRIBUTE, CHANGE-ATTRIBUTE, DELETE

Back to content

Using FTAC profiles by remote partners

In order to use an FTAC profile in an FT responder, the initiator must specify the transfer admission of this profile. He can send the transfer admission either as the initiator identity, or as the filestore password. If it is sent as initiator identity, the filestore password must be omitted, or it must be empty (string length 0). If it is sent as a filestore password, the initiator identity must be omitted.

In some cases, the initiator can omit neither the initiator identity nor the filestore password, and thus he will not be able to use FTAC profiles. Starting from FT V7.0A50 on UNIX platforms resp. FT V7.0A40 on Windows platforms, it will be possible to specify a reserved password *PROFILE in order to address FTAC profiles by the transfer admission (in the initiator identity) even if a filestore password must be given by the initiator.

Back to content

Properties due to internal caches

Changes in the FTAC standard admission set and in a Transport Name Server (TNS) database FTAM entry don't get effective in any case in the FTAM server. If the FTAM server is stopped and restarted, these changes will be valid. In the case of TNS entries, you can issue an ft transfer request to an alternative FTAM partner instead (maybe using an invalid transfer admission), and after this the changes for the original FTAM partner are valid.
The reason for this are caches for the standard admission set and for one partner assignment, which make changes outside the FTAM server invisible.

In the most recent V8 releases, the caching has been removed resp. amended. Thus, it should be no longer necessary to restart the FTAM server in these cases.

Back to content

No FTAM trace in UNIX platforms?

In FT V7.0A00 and V7.0A10, the FTAM trace cannot be switched on (or off) on some UNIX platforms (for example HP-UX). Furthermore, the creation of new keys (fta -k) may result in an error, and diagnostic codes AC/YFTCF 01/ 000C may be written. All these problems can be fixed by an upgrade to V7.0A20 (or more recent versions).

Back to content

The FTAM catalogue and ftvfsm

The FTAM catalogue stores FTAM file attributes which are not known to the real system. The most important attributes stored here are format describing attributes like contents type, universal class number and string format. In the FT interface description, those attributes are often called file type, character set, and record format. It may be more convenient to work with the FTAM catalogue, because the file format need not be specified in file transfer requests if it is stored in the FTAM catalogue entries. On the other hand, an explicit specification of a file format in a file transfer request must coincide with the information in the FTAM catalogue.

On UNIX platforms, the FTAM catalogue is a DISAM database, the file name being the index key. DISAM is an external product which is used by FT. If an FTAM file is created, also an FTAM catalogue entry is created in the DISAM database. If the file is deleted by means of FTAM, also the corresponding catalogue entry is deleted. If the file is deleted locally, the corresponding catalogue entry stays alive. These catalogue entries without a real file may cause the following problems: first, the FTAM catalog may grow and grow by the time, and second, a locally created file with a name earlier used may "inherit" improper attributes.
Additionally, the FTAM catalogue might be damaged in the case of disk shortages, or in some cases if there are too many entries of files of similar names in it. The process ftvfsm helps to avoid those problems as far as possible. It is started together with the FT servers, and it erases the catalogue entries without an existing file once a day. In some applications, the cleaning once a day seems to be not enough. ftvfsm may also be called as a command, and it could be started (for example) once an hour by an automatism like crontab. It is also possible to work without the FTAM catalogue if you erase the directory /opt/openFT/ft/FTATTR. In FT V8 and later, the FTAM catalogue is no longer based on DISAM, but it is a subdirectory /var/openFT/<instanceName>/FTATTR containing up to 16 subdirectories with up to 16 files each. The instance name is normally std. The risk of FTAM catalogue damage has been reduced essentially by this solution.

On Windows NT and Windows 2000, each FTAM catalogue entry is an "appendix" to an NTFS file. The problem of keeping the FTAM catalogue consistent with the existing files doesn't exist here. Non-NTFS files cannot have an FTAM catalogue entry. It is also possible to switch off the FTAM catalogue function on Windows platforms by specifying a value BYPASSVFS of type REG_SZ in the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\openFT\CurrentVersion
set to "1".

For NTFS files on Windows NT/2000 and for files on UNIX platforms, it is possible to see the contents of an FTAM catalogue entry using ftshwf -l <filename>. If and only if there is no FTAM catalogue entry, the output will contain neither a BINARY-FILE nor a CHARACTERSET nor a RECORD-FORMAT specification. In order to create or modify an FTAM catalogue entry the command ftmodf can be used. If no file format attributes are specified in this command, they are set to CHARACTERSET=g RECORD-FORMAT=v if the catalogue entry didn't exist before, else they remain unchanged.

You can specify a file access password using the parameter -np=<password> in the ftmodf command. This password is significant only for file transfer requests (sending and receiving) and deletion requests initiated by remote partners. ftmodf -np=@n removes this password protection.
Starting from version V7.0A20 (Windows platforms) resp. V7.0A30 (UNIX platforms) it is also possible to delete FTAM catalogue entries without deleting the associated file: ftmodf <filename> -np=@d will do this.

FTAM catalogue entries are not set by FT protocol requests, but they may affect them. For example, a file created as a binary file by an FTAM protocol request can be transferred by an FT protocol request only if the binary option is set.

Back to content

Tabulator expansion and Escape Sequences in FTAM

FTAM text files may contain control characters, and they may contain escape sequences, for example for switching between character sets like ISO8859-1, ISO8859-2. It depends on the universal class number resp. the character set whether control characters and/or escape sequences are allowed or not.
In principle, FT doesn't check these rules, that means, neither a local file to be transferred nor a data stream is checked for "illegal characters". There are two facts, however, which may modify the binary contents of a file.

The Tabulator Expansion
Files of the character set types graphic string and visible string cannot contain control characters; especially they cannot contain tab signs. Each tab sign is substituted therefore by one to eight space characters, as if there were tabulator positions 1,9,17 and so on. This behaviour is compatible with the tabulator expansion in the FT protocol solution. IA5 string and general string files leave tab signs unchanged.

Escape Sequences
In graphic string and general string files it is possible to specify character set switching escape sequences. These escape sequences are not part of the text, but they may switch proper character imaging devices from one representation of characters (like West European) to another one (like Greek). openFT-FTAM as a sender of such a file assumes that there is an ISO 8859-1 file to be sent, and the appropriate escape sequences are added as a header of each string. openFT-FTAM as a receiver removes those escape sequences which indicate ISO8859-1 or somewhat compatible. More exactly, the following escape sequences are removed:

  • 1B 28 42
  • 1B 28 40
  • 1B 2D 41
  • 1B 2D 7E
  • 1B 21 40
  • 1B 21 7E
  • 1B 7E

Any other escape sequence is preserved. In visible string and IA5 string files, there are no escape sequences, and openFT-FTAM leaves any sequence of characters starting with ESC (1B) unchanged.

In openFT versions V8.1 and later, the insertion and removal of escape sequences can be switched off even for graphic string and general string. Setting the environment variable NOESCSEQ to 3 will do this. NOESCSEQ=1 switches off the insertion, but does not affect the removal of escape sequences. NOESCSEQ=2 keeps all the escape sequences on file receiving, but does not affect the insertion of escape sequences. It is recommended to set NOESCSEQ as a system wide environment variable if needed.

Conclusion
"Legal" characters are always mapped correctly. The maximum transparency concerning the binary representation of a text file including "illegal characters" can be achieved using the IA5 string: neither the tabulator expansion nor the processing of escape sequences is effective in this case.

Back to content

Special termination handling for the "Elektronische Öffnung der Deutschen Bundesbank" standard

A file transfer or file management action is successfully completed after F_CLOSE and F_DESELECT have been successfully processed. The subsequent processing is either a new transfer or file management action on the same FTAM connection, or the termination of the FTAM connection.

For this reason, FT does not care about the way of terminating the FTAM connection; once the file transfer or file management action can be regarded as successful it returns a message and a reason code indicating success. The "Elektronische Öffnung" standard, however, expects that a previously performed file transfer has to be regarded as not successful when some failure or transport disconnect occurs during the exchange of F_TERMINATE request/response.

This may lead to the situation that a transfer is regarded to be successful from the FT initiator's view, whereas the responder's view on "Elektronischer Öffnung" is that the transfer has not been performed. To overcome this situation, a new environment variable has been introduced (since version V8.0B available).
ELEKOEFF can be set to one of the following values:

1 failures in the termination of the FTAM connection are always regarded as a failure of the preceeding file transfer or file management action.
not def. failures in the termination of the FTAM connection don't affect the result of the file transfer or file management.
prefix If the specified prefix matches the partner name in the length of the prefix, failures in the FTAM connection termination will be evaluated. For all the other partners, failures in the FTAM connection termination will be ignored.

ELEKOEFF can be set as a user variable if only one user or a limited number of users interwork with a "Elektronische Öffnung" server using only synchronous request. It is better, however, to set ELEKOEFF as a system wide variable before starting the FT servers. Windows platforms have to be restarted afterwards to make this switch work for asynchronous file transfer requests.

Warning: Don't use this ELEKOEFF option for partners which are not conformant to the "Elektronische Öffnung" standard in the sense described above, especially not for FT responders. FT responders don't keep any information about a file transfer request as soon as F_CLOSE and F_DESELECT response have been issued.

Back to content

Special workarounds for Omikron partners

Interworking with Omikron partners may cause a lot of problems concerning ASN.1 length encoding and FTAM protocol. Omikron expects ASN.1 length encoding using the minimum number of octets possible. On the other hand, lengths issued by Omikron are not always correct. In the FTAM protocol, Omikron returns document types and service classes which have not been proposed by the initiator in F_INITIALIZE request.

In order to overcome this situation, a new switch ASNMINLEN has been introduced. ASNMINLEN must be set as an environment variable in order to activate workarounds for these problems. If ASNMINLEN is set to any value, the ASN.1 length encoding will be minimized as expected by Omikron for any partner, and the wrong length encodings returned by Omikron will be repaired before decoding.

The workarounds in the FTAM protocol can also be activated only for specific partners. For this, ASNMINLEN can take the following values:

set ASNMINLEN=1 will activate them for all the partners
set ASNMINLEN=prefix will activate them for all those partners with a partner name beginning with the given prefix.

It is not recommended to set ASNMINLEN if OSS is used by a performance critical transaction system (for example UTM). Performance loss might be significant.

These workarounds will be available in the latest V8.0 releases of openFT.

Back to content

Hidden configuration parameters in the fta command

fta...... min.
value		 default
value		 max.
value		   explanation
-hf         must be given in conjunction with every hidden parameter.
-to= 2 5 1500   (Timeout in minutes) If a connection stays idle for more than this number of minutes, it will be aborted.
-ci= 20 60 32767   (Checkpoint Interval) the time in seconds between checkpoints.
-sc= 1 5 32767   (time slice) If there are FTAM requests waiting, a long recoverable transfer interrupts itself after n checkpoint intervals to give preference to another request.
-ri= 20 300 3600   time interval in seconds between the first 5 unsuccessful recovery attempts.
-rl= -ri 3600 32767   time interval in seconds between subsequent unsuccessful recovery attempts - for example if the partner seems not to be active.

The settings of the hidden parameters of the fta command can be seen by the command fti -p -hf=y.

If large files are transferred asynchronously, spontaneous interrupts may occur because of a time slice meachanism even if no further FTAM transfer requests are waiting. In some cases, a subsequent request fails to get active, for example because there is still no free transport connection. The request will get active later, but not before another recovery interval has expired.
In this situation, you can either switch off the time slice mechanism by calling fta -hf -sc=32000, or shorten the recovery interval by calling (for example) fta -hf -ri=40.
Since the latest releases of FT V8, the time slice mechanism has been deactivated as standard.

Back to content

Hidden parameters in the ncopy/ft command

For FTAM partners, you can specify an option -g as an alternative to -t, -b or -u in a ncopy or ft command. This option claims the following file format attribute combination for the transfer:

  • document type: simple text
  • universal class number: General
  • string significance: not significant

This option can be used to avoid tabulator expansion when a file is to be sent and when there is no FTAM catalogue entry for this file possible. If an FTAM catalogue entry can be assigned to the file, it is better to set it by means of the command

ftmodf <filename> -ft=t -cs=c -rf=u

before sending the file instead of using the -g option.

It may be required to avoid the escape sequences for character set switching. This can be done by the selection of the universal class number IA5 String or Visible String. Additionally to the setting of the universal class number in the FTAM catalogue, there exists a more convenient non-official way starting from FT version V8.0B for UNIX and Windows:

-cs=c -cs=i -cs=v

in the ncopy resp. ft command sets the universal class number for the transfer to General resp. IA5 resp. Visible String. This switch must be used in the following combinations:

  • -t -cs=v for Visible string with variable string significance
  • -g -cs=i for IA5 String with not significant
  • -g -cs=c for General String with not significant (same as -g)
  • -t -cs=i for IA5 String with variable
  • -t -cs=c for General String with variable

If the ncopy/ft parameter -r=fnnn is combined (nnn describing a string length) with -t, the string significance is fixed instead of variable. The combinations of IA5 or General String with variable or fixed string significance are new transfer formats (not supported before version V8.0B), but in practise they are very similar to the transfer format of IA5 or General String with Not Significant: <CRLF> are issued resp. interpreted as line delimiters. The file is sent in string portions of maximum string length (if given); on receiving these string portions have no significance for the file structure. In the FTAM catalogue, the files are created with not significant (independent of the transfer format's string significance). On the other hand, files with "not significant" given in the FTAM catalogue, or without an FTAM catalogue entry can be sent in variable or fixed transfer format (with General or IA5 string) by setting these parameter combinations in the ncopy resp. ft command or inbound in the F_OPEN_request.

Warning: Don't use the -g option or the -cs= switch for NEA transfer requests. Results will be unpredictable.

Back to content

Hidden parameters in the program interface for transfer requests

It is also possible to set some of the transfer formats in the C program interface of FT starting from V8.0B. In the structure ft_transpar, filetype can take one of the following values:

filetype like ... in the ncopy command
FT_NOTYPE (no file type given)
FT_TEXT -t
FT_BINARY -b
FT_USER -u
'v' -t -cs=v
'i' -g -cs=i
'c' -g

The fixed string significance format can be selected by ORing the value 0x00100000 to the string length given in maxrecsize.
The variable string significance format can be selected by ORing the value 0x00200000 to the string length given in maxrecsize.

Warning: Don't use values other than FT_NOTYPE, FT_TEXT, FT_BINARY, or FT_USER for filetype in ft_transpar for NEA transfer requests. Results will be unpredictable.

Starting from V8.0B, there exists a way to retrieve "further details" in the FTAM diagnostics to the caller of ft_transfer. If you specify a ft_transftam structure with legalq pointing to a string, this string is normally used to create a legal qualification for the partner file (in sending requests). If the string starts with %%@_#GET_ it is not used as legal qualification parameter, but is reserved for future functions. If it starts with %%@_#GET_FURTHER_DETAILS for synchronous transfer requests, it will be replaced by the further details string (if existing) resp. it will be erased (if there were no further details). The further details string will be truncated if it is longer than the %%@_#GET_FURTHER_DETAILS prefixed string given before the ft_transfer call.

Back to content

Entering values for FT in the registration database of MS Windows systems

Some properties of the FTAM protocol handling in FT can be modified for particular interworking reasons. For the Windows NT/2000 and Windows 95/98/Me platforms, this can be done by setting values in the registration database:

  1. From the Start button, select Run, and type in regedit
  2. The registry editor appears in a Windows explorer like layout. In the left part, open the following subdirectory:
    • HKEY_LOCAL_MACHINE
      • SOFTWARE
        • Siemens
          • FT
            • CurrentVersion
  3. In the menu, select Edit - New - StringValue. A new value entry will appear in the right part of the registry editor window, and you have to change the name of the value appropriately (CALLINGAET, NOFUFILESIZE, FTAMNORTEL, ..). If you already find the value name you need, you can omit this step.
  4. Double click the value name you want to set or modify. A small Edit String window will appear, and you can add the value data here.

Be careful not to modify or delete anything else in the registration database, because it might damage your system! After FT update installations, it is not necessary to repeat this procedure. If you deinstalled and reinstalled FT, you will have to repeat the entering of these special registration values.

Back to content
(c) 1999-2003 Fujitsu Siemens Computers. All rights reserved.