08/27/79 This info segment describes how the MR7.0b release of Multics TP differs from the Transaction Processing manual, Order no. CC96-01. Page ii, Preface: ADD at the end: Implementation Restriction The implementation of the -use_xcn_mode control argument of tp_start is not complete. This control argument should not be used. All claims about and references to commiting transactions, rolling back transactions, having database changes appear atomically and rolling back database changes after a crash should be ignored. In particular, the transaction_call_ interfaces described in section 4 and the -transaction attach description control argument of vfile_ described in MPM Subroutines are not completely implemented. Page 1-1, List of Features: ADD "if the -use_xcn_mode control argument of tp_start was specified" to the first two items. Page 1-2, second paragraph: ADD to the end: "This applies only if the -use_xcn_mode control argument of tp_start was specified." Page 1-3, Figure 1-1: REPLACE "Monitor" by "Subsystem". Page 1-4, third paragraph: REPLACE the beginning of the third sentence from "Databases" to "If the -use_xcn_mode control argument of tp_start was specified, databases". INSERT "be" after "changes to" in the fourth line. Page 2-4, Step 10: REPLACE the first exec_com, the second paragraph and the second exec_com by: & Prepare MRDS databases application_open_mrds_db db_id1 dsm_path1 application_ready_mrds_file db_id1 file_name1 rdy_mode1 collection_delay_time1 . . . application_ready_mrds_file db_id1 file_nameI rdy_modeI collection_delay_timeI . . . application_open_mrds_db db_idN dsm_pathN . . . &quit The application_open_mrds_db and application_ready_mrds_file commands are written by the TP Administrator. See Section 6 for more information about writing these commands. The following is tp_init_database.ec for the Sample_TP project: & Prepare MRDS databases sample_tp_open_mrds_db people people_db sample_tp_ready_mrds_file people people monitor_retrieve 90 sample_tp_open_mrds_db inventory inventory sample_tp_ready_mrds_file inventory inventory update 300 sample_tp_ready_mrds_file inventory parts update 300 &quit Page 2-5, Step 11: DELETE "All segments in the comands directory are explicitly initiated to reduce overhead." REPLACE the example worker process absentee control segment by the following: change_wdir &1 tp_worker_init_tcf [wd] & & Attach and open I/O switches io_call attach parts vfile_ parts -stationary -transaction tcf_ -share io_call open parts keyed_sequential_update io_call control parts set_wait_time -collection_delay_time 300 & tp_worker_start &ec_name [wd] &quit ADD to the end of the last paragraph: "The commitment mechanism is used only if the -use_xcn_mode control argument of tp_start was specified. If this control argument was not specified, omit "-transaction tcf_" from the attach description." Page 3-4, tp_cancel: ADD to the paragraph description: "This command may only be used while transaction processing is running." Page 3-5, tp_change_deadline: ADD to the paragraph description: "This command may only be used while transaction processing is running." Page 3-6, tp_display_current_xcns: REPLACE "TP command name and TP_user_id" by "TP_user_id and TP command name". ADD to the paragraph description: "This command may only be used while transaction processing is running." Page 3-7, tp_get_xcn_status: REPLACE the paragraph description by: The tp_get_xcn_status command prints information about transactions. If the transaction has not been processed the following information is printed: transaction number, state, TP user who submitted it, TP command name, if it is test mode, I/O process it was submitted from, submission time and deadline. If the transaction is running, the following information is also printed: worker process, time started and time from submission to processing. If the transaction has finished running, the following information is also printed: time finished, start to finish time, submit to finish time and if nonzero the vcpu time, page faults and retries. If the transaction was canceled, the information for an unprocessed transaction is printed along with the cancelation time as the finish time and the time from submission to cancelation. This command may only be used while transaction processing is running. REPLACE the description for control_arg by "may be -brief or -bf to print only the transaction number and its state." Page 3-8, tp_list_pending_requests: ADD to the paragraph description: "This command may only be used while transaction processing is running." REPLACE the description of the -long control argument by: "prints the transaction number, position in the queue, deadline, TP user who submitted it and submission time for each pending transaction. The default prints only the position in the queue and transaction number." Page 3-9, tp_start: ADD to the control arguments section: -use_xcn_mode specifies that vfile_'s transaction mode should be used in this TP subsystem. This allows database changes in a transaction to appear atomically and allows transactions to be rolled back. -no_use_xcn_mode specifies that vfile_'s transaction mode should not be used in this TP subysystem. This is the default. ADD to the "Notes" section: The -new_master control argument is incompatible with the -use_xcn_mode and the -no_use_xcn_mode control arguments. If the -no_use_xcn_mode control argument is specified and Multics crashes in the middle of a transaction or before the transaction is marked as completed, the transacton is rerun. Database changes made by the transaction before the crash are not rolled back. If an application only reads databases, or an application is not written to depend upon transaction mode, then it is more efficient to specify -no_use_xcn_mode. Also, test mode is not available if -no_use_xcn_mode is specified. Page 3-11, tp_who: ADD to the paragraph description: "This command may only be used while transaction processing is running." ADD to the description of the TP_user_id argument: "The default prints information about all TP users that are signed on." REPLACE the description of the -long control argument by: "prints the I/O process name, device channel name, baud rate, terminal type, terminal id and TP_user_id. The default prints the TP_user_id and I/O process name." ADD to the description of the -io_process control argument: "More than one -io_process control argument may be specified." Page 3-13, tp_rollback_transaction_: ADD the following as a "Notes" section: Database changes are rolled back only if the -use_xcn_mode control argument of tp_start was specified. Page 3-14, tp_verify_transaction_: ADD the following as a "Notes" section: If the -no_use_xcn_mode control argument of tp_start was specified, the code argument will always be zero since asynchronous changes only occur in transaction mode. Page 3-20, tp_io_enter_test_mode: ADD the following as a "Notes" section: Test mode transactions may be run only if the -use_xcn_mode control argument of tp_start was specified. Page 3-22, tp_io_get_xcn_status: REPLACE the paragraph description by: The tp_io_get_xcn_status command prints information about transactions submitted by the TP user. If the transaction has not been processed the following information is printed: transaction number, state, TP command name, if it is test mode, submission time and deadline. If the transaction is running, the following information is also printed: time started and time from submission to processing. If the transaction has finished running, the following information is also printed: time finished, start to finish time, submit to finish time and if nonzero the vcpu time, page faults and retries. If the transaction was canceled, the information for an unprocessed transaction is printed along with the cancelation time as the finish time, and the time from submission to cancelation. REPLACE the description for control_arg by "may be -brief or -bf to print only the transaction number and its state." Page 3-23, tp_io_list_pending_requests: In the paragraph description, REPLACE "user" by "TP user". REPLACE the description of the -long control argument by: "prints the transaction number, position in the queue, deadline and submission time for each pending transaction. The default prints only the position in the queue and transaction number." Page 3-35, tp_meters: REPLACE the seven metering information points in the paragraph description by: xo number of unprocessed, successful, commitment failure and error transactions. Cancelations are included in the error total. xo number of transactions submitted and submissions per minute, broken down by I/O process and by TP user. xo for processed transactions, the number, number per minute, average submisission to start time, average start to finish time, average vcpu time, average page faults and average retries, broken down by worker process and by TP command. REPLACE the usage line by: tp_meters {path} {-control_args} ADD to the description of the path argument: "The default is tp.tpinq in the working directory." Page 3-38, tp_shrink_q: REPLACE the usage line by: tp_shrink_q {path} {-control_args} ADD to the description of the path argument: "The default is tp.tpinq in the working directory. ADD to the first paragraph in the "Notes" section: "One of the -delete or -output_description control arguments must be specified." Page 5-1: ADD to the end of the first paragraph: "If the -no_use_xcn_mode control argument of tp_start was specified, database changes from incomplete transactions are not discarded." REPLACE "Then the worker process rolls back ... next transaction." in the third paragraph by: "If the -use_xcn_mode control argument of tp_start was specified, any changes made by the transaction are rolled back. The worker process then goes on to the next transaction." ADD to the end of the last paragraph: "Asynchronous changes only occur if the -use_xcn_mode control argument of tp_start was specified." Page 6-2, File Input/Output section: ADD to the end of the second paragraph: "The commitment mechanism is used only if the -use_xcn_mode control argument of tp_start was specified. If the -no_use_xcn_mode control argument was specified, asynchronous changes don't occur and it is not necessary to handle the asynchronous change problem." Page 6-3, Using MRDS section: REPLACE by: All databases used by any TPR should be opened in tp_init_database.ec to reduce the overhead associated with a TPR. All files of a database that will be used should also be readied. When a TPR is invoked, all its databases should be open and all files that it will use should be ready. TPRs should not finish a file or close a database. The -control control argument of create_mrds_db should be used and should specify the TP subsystem's TCF if vfile_'s transaction mode is used in this TP subsytem. The TP Administrator should write two commands for tp_init_database.ec. See Section 2, Step 10. The first command, application_open_mrds_db, is used to open a MRDS database. This command should save the MRDS database index in an external static variable. The database id argument, db_id, is used to identify which database is being opened and consequently which external static variable to save the database index in. If vfile_'s transaction mode is being used, application_open_mrds_db should also call dsl_$set_tcf_switch to change the TCF I/O switch to tcf_. The second command, application_ready_mrds_file, is used to ready a MRDS file. This command should use the database id argument, db_id, to identify which database contains the file and consequently which external static variable contains the database index for the open database. The file to ready and the ready mode are arguments on the command line, file_name and rdy_mode respectively. If transaction mode is being used, a collection delay time should be specified. The collection delay time should be longer than the real time any transaction that uses the file will require. The application_ready_mrds_file command should call dsl_$set_collection_delay_time with the specified collection delay time. To ensure repeatability if an asynchronous change occurs in transaction mode, only the monitor_retrieve or update ready modes should be used. The remaining problem is how to get the database index to a TPR. Call conventions should pass the database indices to TPRs as arguments. A call convention should pass all the database indices that any TPR using the call convention may need. If the TPR is written in PL/I, it may use the external static variable containing a database index directly. Page 6-5, Commitment and Rollback Features: ADD to the beginning of the first paragraph: "This section describes the commitment mechanism enabled by the -use_xcn_mode control argument of tp_start." Page 6-6: ADD the following paragraph at the end: If the -no_use_xcn_mode control argument of tp_start was specified, the commitment mechanism is disabled. All database changes made by TPRs are performed immediately. Their effect is permanent and other users will see the change when the change is made. Commitments and roll backs are not performed if transaction mode is not being used. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved