Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Multiple Destination Secondary Transactions

IP.com Disclosure Number: IPCOM000042872D
Original Publication Date: 1984-Jun-01
Included in the Prior Art Database: 2005-Feb-04
Document File: 2 page(s) / 29K

Publishing Venue

IBM

Related People

Bailey, CG: AUTHOR [+2]

Abstract

In IMS (Information Management System) ADF (Application Development Facility), execution of one user transaction can require another transaction to be executed. This is called a secondary transaction. Early versions required that such transactions be processed through IMS message queues. With IMSADF II, secondary transactions can be sent not only to an IMS logical terminal (LTERM) and another IMS transaction; they can also be sent to a sequential operating system (OS) file. This is done in such a way that the application developer does not have to change the definition of the transaction process. Rather, the destination of the secondary transaction is controlled in the message data base (MSGDB) and does not involve either the transaction definition or the secondary transaction.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 74% of the total text.

Page 1 of 2

Multiple Destination Secondary Transactions

In IMS (Information Management System) ADF (Application Development Facility), execution of one user transaction can require another transaction to be executed. This is called a secondary transaction. Early versions required that such transactions be processed through IMS message queues. With IMSADF II, secondary transactions can be sent not only to an IMS logical terminal (LTERM) and another IMS transaction; they can also be sent to a sequential operating system (OS) file. This is done in such a way that the application developer does not have to change the definition of the transaction process. Rather, the destination of the secondary transaction is controlled in the message data base (MSGDB) and does not involve either the transaction definition or the secondary transaction. The IMSADF II rule generator is used to define the transaction process and the format of the secondary transaction. These definitions are in the input transaction rule (ITR) and the output format rule (OFR), respectively. At execution time, IMSADF II processes the ITR. Based on the results of execution, it may or may not be necessary to send the secondary transaction. This can be determined based on successful execution of the transaction, errors encountered in transaction processing, audit logic, or immediate requirements. If the secondary transaction is required, IMSADF II builds it according to the OFR and uses the single point of control, rep...