781-285-4236 T.
781-934-8996 F.

Frequently Asked NonStop AutoTMF Questions

Getting Started Questions
Scope of Functionality Questions
Application Management Questions
Automatic Transactions Questions
Performance and Resources Questions
Diagnostic Tools Questions

This area contains questions and answers for the NonStop AutoTMF product. If you require further assistance please contact us.

Getting Started Questions

1. Does AutoTMF require TMF?
A) Yes. AutoTMF operates on audited files so it requires the TMF subsystem to be running.

2. Does AutoTMF require RDF?
A) No. The function performed by AutoTMF is to allow non TMF-aware programs to access audited files. It is therefore compatible with any software product that uses TMF audit trails for replication.

3. What release of Guardian is required for AutoTMF?
A) AutoTMF is supported on all RISC platforms that run Guardian D30 or later. It uses only published interfaces and is not Guardian release dependent.

4. If AutoTMF is release-independent, what must be done when I upgrade my NSK system release?
A) The AutoTMF runtime contains versions of the COBOL85, C and CRE runtime libraries. (This allows the interception of Enscribe calls issued by the language runtime libraries). There are currently 4 versions of these libraries that span the Guardian releases supported by AutoTMF. All are supplied in the AutoTMF installation subvolume. At installation time, the user is prompted to enter the release level of the system and the appropriate version of the runtime is selected and installed in the product subvolume.

5. Does AutoTMF require the use of a super Id?
A) No. AutoTMF contains no privileged code and does not require the use of a super ID. It can be integrated with the security rules in place on your system.

Scope of Functionality Questions

6. For best use of AutoTMF should one already have a transaction monitor like Pathway or BASE24?
A) AutoTMF is application independent and functions well with or without a transaction monitor. AutoTMF supports all NSK applications, batch or interactive.

7. What file types can be handled by AutoTMF?
A) AutoTMF supports structured and unstructured Enscribe files. Key-sequenced, entry-sequenced and relative files are supported. In the next release of AutoTMF, automatic transactions for audited SQL tables will be supported.

8. Do you recommend auditing object or edit files?
A) No. Audited object files cannot be executed; this is a restriction imposed by the NonStop Kernel. Audited edit files could be accessed if the Tandem editors (TEDIT, EDIT and VS) are prepared for AutoTMF, but edit files that are replicated with RDF will often be unusable. Editors move the file EOF backwards, an operation that is not audited by TMF or replicated by RDF.

9. Does AutoTMF support auditing spooler control and data files?
A) Yes. Spooler files can be audited and recognized by AutoTMF. Auditing spooler files requires that the spooler subsystem programs (collector, supervisor, etc) be prepared prior to starting the spooler.

10. What application languages are supported by AutoTMF?
A) AutoTMF supports applications written in all languages including C, Cobol 85 and TAL. To support languages such as Fortran, Pascal and Cobol 74 will require adding the language runtime support to the AutoTMF user library

11. Are TACL-operations like RENAME, COPY, PURGE or FUP operations like COPY, PURGE and RENAME supported? Can I LOAD an audited file and, thus, replicate it at the same time?
A) TACL is a non-privileged application. It may be prepared and all of its Enscribe operations will be intercepted by AutoTMF and automatic transactions will be managed as they would for any program.

FUP can be prepared to use AutoTMF as described in Section 5 of the AutoTMF User's Guide, and will provide functionality for COPY, PURGE, and RENAME. LOAD performs unstructured writes to structured files; this operation is not allowed on audited files.

12. What Enscribe file operations does AutoTMF support?
A) All Enscribe I/O procedure calls are supported. These include all the various OPEN, POSITION, READ, and WRITE operations. In addition, CREATE and RENAME of audited files can be configured.

13. Does AutoTMF support transactions for audited SQL tables?
A) In the initial release, AutoTMF supports the automatic generation of transactions for Enscribe files and Escort SQL mapped tables. Support for audited tables accessed with embedded SQL may be implemented in a future release of AutoTMF. No specific commit date because so few customers/prospects have requested this feature.

14. What happens if my application creates files on the fly that we now want audited?
A) AutoTMF has a configurable CREATEAUDIT feature that allows a user to specify that a file should be created with the audit flag. Since this CREATE operation is audited, it can be replicated.

15. Certain files need to be audited for replication and disaster recovery. Is there an easy way to identify which programs would need to use AutoTMF to audit this fileset?
A) There is no need to avoid preparing programs that do not require AutoTMF. If you simply prepare all application object files, AutoTMF will determine when automatic transactions are required. Programs that do not update audited files will not generate transactions.

16. What if I already have TMF in my programs but not all files are audited?
A) With AutoTMF, files that were previously unaudited can be audited and configured to be protected under a separate automatic transaction. Since automatic transactions are always committed, updates to these files are committed even if the application fails or calls ABORTRANSACTION.

17. None of our data files are audited today. To use AutoTMF, do we have to audit all files accessed by our programs?
A) No. You choose which files to audit. AutoTMF generates automatic transactions to access audited files whenever they are needed; accesses to unaudited files do not need a transaction.

Application Management Questions

18. Does AutoTMF require any change to the application logic? Must I recompile my programs?
A) No. In order to enable AutoTMF, a simple preparation is performed on the object file.

No source are required. AutoTMF does not require recompilation, rebinding, SQL compiling or re-acceleration. Even stripped files can be prepared

19. How do application programs invoke AutoTMF?
A) AutoTMF is completely automatic; it does not require any invocation by applications. Once the applications has been prepared, accesses to audited files are monitored and AutoTMF supplies TMF transactions whenever necessary.

20. Is preparation like a SQL compile? If I move or copy a program object to another location, do I need to prepare it again?
A) No, preparation is more like acceleration, except that it takes a fraction of a second per object file and unless a program is recompiled, it never needs preparation again.

If you move a program to another system where the user library does not reside in the same place you would need to point the program to the new library.

21. How do I determine which object files are prepared for AutoTMF?
A) Use the Escort INFO PROGRAM command to generate a report on all object files in a file set. For example:

run escort /out tempfile/ info program $*.*.*;

This will produce in tempfile a list of files. If you use Edit and L/Prepared/ (note the capital P) you will get a listing of the Prepared programs

You can also see which object files are not (yet) prepared by using the UNPREPARED option. For example:

run escort /out tempfile/ info program $*.*.*, unprepared;

22. If a database file that is protected by AutoTMF is moved to another location, apart from setting the audit flag on the database file, is there any further action that needs to be taken ?
A) If no special AutoTMF attributes have been configured, then no further action is required. If the files have special AutoTMF attributes, then the AutoTMF configuration must be updated to specify attributes for the new file names.

23. If the user forgot to prepare on one or more of the object files, what happens when the program writes to an audited file?
A) If a program has not been prepared, the update or insert to an audited file will not be performed because the I/O will fail with an error 75 ("Requesting process has no current process transaction identifier") unless the program has a transaction of its own. TMF guarantees that no update can be performed on a file without an active transaction.

24. AutoTMF is implemented as a user library. What happens if the application programs already point to a user library?
A) If the application programs already use a library, it needs to be combined with the AutoTMF library file before the programs can be prepared to use AutoTMF. This simple procedure is fully documented in the AutoTMF User Manual

Automatic Transactions Questions

25. Does AutoTMF determine where business transactions begin and end? Will it keep my database consistent from a business viewpoint?
A) AutoTMF does not claim to understand what a business transaction is. However, the natural locking and unlocking behavior of an application normally causes AutoTMF to commit transactions at the end of a business transaction. AutoTMF transactions do not span multiple processes.

26. How does AutoTMF know when to start a transaction?
A) AutoTMF intercepts all Enscribe calls issued by an application program. If a transactional operation is issued against an audited file but no TMF transaction is active, AutoTMF starts an automatic transaction.

27. How does AutoTMF know when to end a transaction?
A) AutoTMF has a complex set of processing rules to manage transactions. The are two basic rules:

  1. All automatic transactions must be committed; no updates should ever be rolled back due to transaction abort.
  2. All locking protocols should be observed. No record or file lock should be released by an automatic transaction commit unless the application has unlocked the records or file.
Given these "rules," AutoTMF has a number of strategies to decide when to commit transactions. It normally assumes that each server request is a single transaction. It also tries to balance efficiency (i.e., using a single transaction for many updates) and concurrency (not keeping records locked by a long-running transaction). Finally, it respects the need for isolation to avoid lock contention between cooperating processes.

28. How do TMF-transactions and AutoTMF transactions operate together?
A) AutoTMF generates its own transactions and does not interfere with transactions generated by the application program. They simply coexist. The only practical restriction is that TMF allows only 100 active transactions in a single process.

29. Is it possible that AutoTMF will perform an abort in some special situations so writes on audited files will be rolled back?
A) AutoTMF never aborts a transaction. The only time a rollback can occur is in the case of a unilateral abort, which happens when the system aborts a transaction because of a catastrophic failure (CPU failure for example) or when a process is stopped by external means.

30. What happens if my application program traps or abends for any reason? Does AutoTMF abort transactions if the program abends?
A) AutoTMF detects the call to ABEND as well as traps and commits all automatic transactions before the process terminates. AutoTMF never aborts transactions. It preserves the behavior of the a unaudited application; updates should be permanent even if the program fails.

31. What happens in the case of a unilateral abort?
A) If an external failure or a STOP command causes the program to terminate, active transactions are aborted by TMF including those generated by AutoTMF.

In normal cases, this simply causes that last few updates performed by the program to be rolled back; generally it has no effect on database consistency unless the process has communicated those updates to another process or file. The user can control this effect by configuring stronger program isolation.

32. Will AutoTMF introduce any new locking problems?
A) The lock protocols of audited and unaudited files are significantly different. For example, locks on undated records cannot be released until the transaction commits.

AutoTMF has been engineered to avoid lock contention and deadlocks, but complex sequences of database operations between cooperating processes may result in increased lock contention. In these cases, the user should specify stronger isolation between processes.

To better understand locking patterns in a program, an improved LISTLOCKs command and deadlock detection is provided in the AutoTMF command interpreter to help identify locking.

33. Does AutoTMF place limits on the duration of a transaction? Are AutoTMF transactions subject to the TMF AutoAbort time limits?
A) Yes. By default, AutoTMF limits automatic transactions to no more than 16 seconds; generally automatic transactions last no more than a few seconds. The user can configure another limit on transaction duration but this should always be much less than the Auto Abort time.

Committing automatic transactions does depend on application program behavior. If the application keeps record locks for an extended period of time, AutoTMF may be forced to wait to commit the transaction that holds the lock.

Performance and Resources Questions

34. What are memory requirements for AutoTMF?
A) Each executing process uses an extended segment of 64K bytes to store internal information. Only a small portion of this 64K of virtual memory is actually used by typical programs, so physical memory requirements are small.

You can configure up to 4 volumes for the extended segment's swap files using global parameters, so you do not need to worry about running out of space on the volume where the object files reside.

35. I have a program that writes an unstructured file using Bulk I/O operations. Can I use AutoTMF to replicate these files. What about writes to structured files using Bulk I/O?
A) Bulk I/O operations to unstructured audited files are converted to multiple 4K block operations. These are the largest block writes that can be audited by TMF.

Unstructured writes (either Bulk I/O or shorter writes) to audited structured files are not permitted by TMF; in order to ensure file structure consistency and prevent broken files, TMF allows and audits only logical record updates.

36. How does AutoTMF impact application performance?
A) AutoTMF itself adds very little extra processing to the application program. The performance of an application with AutoTMF is approximately the same as the application would be if it had been designed to use TMF transactions.

Performance is generally improved by auditing files, especially in batch workloads because the newly audited files are now buffered. Another major area for potential performance improvement is through TMF audited files eliminating block-splitting overhead.  See the Fall 2003 ITUG presentation of one such user: Performance Characteristics of Audited and Non-Audited Files

The increase in CPU cycles for TMF auditing is largely offset by more efficient I/O access.

Also, operations such as backup can be performed while the file is being accessed by applications, removing the need to stop the application for database maintenance and potentially speeding up batch runs.

37. What is the operational impact of AutoTMF?
A) AutoTMF requires very little management. The AutoTMF monitor must be started after a system cold load, but is fault-tolerant.

As for the operational aspects of auditing files, they are no different than if the application had been rewritten to use TMF transactions. Users should conform to the operations guidelines recommended by Compaq.

38. Does the use of AutoTMF have advantages for making backups of open application files?
A) BACKUPs of open files that are being updated are often corrupt when they are restored. Even if they are not corrupt, the data is inconsistent and out-of-date. With audited files and TMF Online Dump, open files can be backed up and restored consistently, with all transactions up to the time of the restore.

39. What information is logged to EMS?
A) When the monitor starts and stop, it logs information to EMS. Otherwise, only exception conditions and AutoTMF related errors are logged by the monitor and the AutoTMF runtime.

40. What happens when the AutoTMF monitor aborts or fails during a double CPU-failure?
A) If the AutoTMF monitor stops for any reason, applications that are already executing will continue to execute unless they open an audited file and need AutoTMF configuration information from the monitor; at this point they will fail and EMS message will be generated.

If a program is started when the AutoTMF monitor is down, the program will execute the same as it would if AutoTMF were not installed. Thus, in the worst case of AutoTMF malfunction, one could stop the AutoTMF monitor and unaudit the database. Then the application would execute the same way it would without AutoTMF.

Diagnostic Tools Questions

41. How does the tracing facility of all I/O's work?
A) The AutoTMF runtime intercepts all calls to Enscribe and SQL so it is able to log these in a trace file.

Home | Products | Escort SQL | AutoSYNC | AutoTMF  | SDR | Ranger | Journaling | Evaluation Program | News & Updates | Training | Support | Distributors | About Us | Links | Contact Us
Copyright © 1996-2012, Carr Scott Software Incorporated. Website designed by DLFwebgroup