Data adapter transparent to application I/O path5732269Abstract An adapter interface function allows data to be acted on using resources owned by a corresponding application and without any modification to the application. The adapter interface can be applied to receive data from data sources not provided for in the access methods used by the application. Likewise, the adapter can be used to write data to data sinks not supported by the access methods used by the application. The adapter interface can be provided in an I/O control system or in access method programs. Adapters are written in an interpreted language to provide run-time execution and avoid program compile, assemble, and link edit requirements. A programing interface is provided to enable invocation of stored library programs. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// DISP=(NEW,CATLG),UNIT=TAPE,VOL=SER=TEMP,
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
7.//BILLER JOB
8.//STMT EXEC PGM=BILLER
9.//INPUT DD DSN=BILLING.DATA,
10.// DISP=OLD,
11.// LRECL=120,BLKSIZE=32760,RECFM=FB
12.//OUTPUT DD SYSOUT=*
______________________________________
The first line of the program indicates to the operating system the name of the job. The second line of the program is a job step named "CALC", and initiates execution of the RATER application. In the third line of the program, the "customer.usage" file is defined, which serves as the input data to the RATER application. After reading the contents of the customer.usage file, RATER closes it. In the fourth line of the program, the file "billing.data" is defined, which serves as the output file for the RATER application. The billing.data file will exist on a storage medium, such as tape. The fifth line of the program defines the disposition (DISP) of the data as NEW for this invocation and is meant to be kept and registered in a catalog for later use. The media to be used for the data output is defined as a tape (UNIT=TAPE) and the tape volume is defined as a standard label tape with a volume serial of TEMP (VOL=SER=TEMP). The sixth line of the program provides the characteristics of the output data set: "LRECL" referring to a logical record length; "BLKSIZE" referring to the size of a block of records to be transferred and "RECFM" referring to the record format, in this case the records are a fixed length and are blocked. The seventh line of the program indicates the start of the BILLER application or job, with the eighth line being a job step initiating execution of the BILLER application. On the ninth line of the program, the billing.data file is defined, which is opened by the program for input. The tenth line of the program indicates that the billing.data file is an already existing file (OLD) and to retain the file when BILLER ends. Lines 5 and 10 are used to define the media, the processing disposition, and the location of billing.data. The eleventh line of the program indicates the characteristics of the data. After formatting the data, the BILLER application closes the billing.data file, and the twelfth line of the program defines the target for the output stream for printing. FIG. 8 depicts one example of the flow associated with the billing process of Company X employing a piping capability for enabling data flow parallelism. One example of an I/O control system which provides a piping capability is known as BatchPipes.TM., the manual for which, entitled "IBM BatchPipes/MVS," is herein incorporated by reference in its entirety. Initially, as with FIG. 7, the data indicating services used is at some point stored on a storage device (STEP 52, "STORE DATA ON STORAGE DEVICE"). The RATER application then opens the file containing the services-used data, reads. the data and calculates the charges (STEP 54, "READ DATA AND CALCULATE CHARGES"). As RATER is processing the data, it is transferred into a pipe for reading by the BILLER application (STEP 56, "CHARGES TO PIPE AS PROCESSED"). Concurrent with the RATER application processing the data and placing it in the pipe, the BILLER application reads the charges placed in the pipe (STEP 58, "READ CHARGES FROM PIPE) and formats the charges for printing (STEP 60, "FORMAT BILL"). After formatting the piped data, the BILLER application sends the formatted data into the output stream for subsequent printing (STEP 62, "PRINT BILL"). An exemplary JCL implementation of the flow diagram of FIG. 8 is given below:
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// SUBSYS=BP01,
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
7.//BILLER JOB
8.//STMT EXEC PGM=BILLER
9.//INPUT DD DSN=BILLING.DATA,
10.// SUBSYS=BP01,
11.// LRECL=120,BLKSIZE=32760,RECFM=FB
12.//OUTPUT DD SYSOUT=*
______________________________________
The exemplary JCL program for the Company X billing process of FIG. 8 is similar to that for FIG. 7, except for the "SUBSYS" lines (lines five and ten), which invoke the BatchPipes.TM. I/O control system, turning over data transfer control thereto. This defines the media as being a pipe in this case, similar to lines five and ten in the previous exemplary JCL program defining real media for the file. The BatchPipes.TM. I/O control system allows the RATER application to process the data and place it in a pipe, while the BILLER application concurrently reads the data from. the pipe and formats it. Thus, the BatchPipes.TM. I/O control system provides a pipeline allowing the RATER and BILLER applications to execute concurrently, significantly reducing the time needed to perform the Company X billing process. FIG. 9 is a topology diagram showing data flow between elements in an exemplary implementation of the flow diagram of FIG. 8. It will be understood that, although not specifically described with respect to this figure and subsequent similar figures, the applications, media, I/O adapters, source/sink adapters and data source/sinks communicate as described with respect to FIGS. 1-5. The following description and the description of subsequent topology diagrams are simplified for ease of discussion. The data indicating services used is accessed from a storage device 64 by the RATER application 66, which then processes the data (i.e., calculates charges) and writes the charges to a pipe 68 as the charges are calculated. Pipe 68 is the only pipe in use between the RATER 66 and BILLER 70 applications. The BILLER application 70 reads the charges from pipe 68 as they are available, formats the charges into a bill and writes the output to a printer 72. Recall that in the description of the exemplary JCL implementation of FIG. 7, the output of RATER was stored in the billing.data file and retained. Assume now that Company X requires a hard copy of billing.data for auditing purposes. As one skilled in the art would know, piped data is transient and is not conventionally written to real media. Assuming Company X desires to retain the elapsed time improvements from piping, but does not want to modify either the RATER or BILLER applications to write an additional copy of billing.data, one conventional solution is to add a job to the pipeline to make a copy of the data file. This job would have to read data from the output pipe of RATER, then write a copy of the data file to both a designated storage media and the input pipe to BILLER. FIG. 10 is a flow diagram of one example of the Company X billing process with an added job named "COPIER" to harden the output of the BILLING application. Initially, as with FIG. 8, the data indicating services used is stored on a storage device (STEP 74, "STORE DATA ON STORAGE DEVICE"). The RATER application causes the file containing the data to be opened, reads the data and calculates the charges (STEP 76, "READ DATA AND CALCULATE CHARGES"). As RATER is calculating the charges, they are transferred into a pipe for reading by the COPIER application (STEP 78, "CHARGES TO PIPE 1 AS PROCESSED"). Concurrent with the RATER application processing the data and placing it in the pipe, the COPIER job reads the data from pipe 1 (STEP 80, "READ CHARGES FROM PIPE 1") and writes the data to physical media (STEP 82, "STORE DATA ON STORAGE DEVICE), as well as writing the data to a second pipe (STEP 84, "CHARGES TO PIPE 2 AS PROCESSED"). The BILLER application reads the data placed in the second pipe (STEP 86, "READ CHARGES FROM PIPE 2") and formats it (STEP 88, "FORMAT BILL"). After formatting the piped charges, the BILLER application sends the formatted data into the output stream for subsequent printing by a printer (STEP 90, "PRINT BILL"). An exemplary JCL implementation of the flow diagram of FIG. 10 is given below:
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// SUBSYS=BP01,
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
7.//COPIER JOB
8.//COPY EXEC PGM=COPIER
9.//INPUT DD DSN=BILLING.DATA,
10.// SUBSYS=BP01,
11.// LRECL=120,BLKSIZE=32760,RECFM=FB
12.//HARDEN DD DSN=BILLING.DATA,
13.// DISP=(NEW,CATLG),UNIT=TAPE,VOL=SER=SAVEIT,
14.// LRECL=120,BLKSIZE=32760,RECFM=FB
15.//OUTPUT DD DSN=BILLING.DATA2,
16.// SUBSYS=BP01,
17.// LRECL=120,BLKSIZE=32760,RECFM=FB
18.//BILLER JOB
19.//STMT EXEC PGM=BILLER
20.//INPUT DD DSN=BILLING.DATA2,
21.// SUBSYS=BP01,
22.// LRECL=120,BLKSIZE=32760,RECFM=FB
23.//OUTPUT DD SYSOUT=*
______________________________________
The exemplary JCL program for the Company X billing process of FIG. 10 is similar to that for the process without piping, except for the addition of a COPIER job in the program (lines 7-17), and the addition of a "billing.data2" pipe. Thus, for a detailed description of lines 1-6 and 18-23 of the JCL program, see the description of the JCL program associated with FIG. 8. Line seven of the above JCL program indicates to the operating system the name of the copy job. The eighth line of the program is a job step named "COPY", and initiates execution of the COPIER job. In lines 9-11 of the program, the "billing.data" file is defined as a pipe for "billing.data" to be received from the RATER application. The COPIER job will read records from the pipe and write each record to the tape file defined in lines 12-14. The name of the file will be billing.data and this file will reside on a tape with the volume serial of "SAVEIT". The file is a new file and its physical location will be kept in a catalog. Each record/block that the COPIER job writes to the tape will also be written to the output pipe to BILLER. The output pipe is defined in lines 15-17 of the program. The name of the pipe can no longer be billing.data, otherwise BILLER would read from the output pipe of RATER and only read a portion of that data, since that is a shared pipe with the COPIER program. Thus, the name of the input pipe for BILLER must be changed; in line 15 the name is specified as "billing.data2". The content of the pipe is a copy of the billing.data file. This requires a change to the control language for the BILLER program to read from the output file of COPIER, so line 20 in the program refers to an input pipe for BILLER with the name of "billing.data2". In order to get the benefit from piping and to meet the requirements of the existing application process, an additional job, initiator, storage, pipe and connections are conventionally used to solve this problem. FIG. 11 is a topology diagram showing the extra resources used as compared to the topology diagram of FIG. 9 (without the COPIER job). The data indicating services used is accessed from a storage device 92. The RATER application 94 processes the data and writes calculated charges to a pipe 96 as the records are processed. The COPIER job 98 reads the charges accessed from pipe 96, writes the charges to a storage device 100 to harden it, and also writes the charges to a second pipe 102 for reading by the BILLER application 104. The BILLER application reads the charges from pipe 102, formats the bill and writes the output to the data output stream for printing by a printer 106. In order to maximize the parallelism for this processing, at least three CPUs would be used, one each for RATER, BILLER and COPIER. As can be appreciated from FIG. 11, the addition of the COPIER job consumes resources over the original billing process implemented with a basic I/O control system. Specifically, an additional pipe and two connections therefor were added. A connection is a job/pipe association when a job invokes an OPEN for a data set that is defined to be handled as a pipe by the I/O control system. An OPEN is an access method service that binds an application to a data set. Also, another initiator was used for the COPIER job. As one skilled in the art will know, an "initiator" is a task or process that starts the execution of an application or job. In addition, there is additional overhead required for piping the data, and path length and data movement and/or data management costs are incurred. Further, the introduction of another application (i.e., "address space") results in additional contention for resources. If swapping is enabled, the COPIER job represents an additional candidate which could be swapped out and thereby diminish the effectiveness of the concurrent execution inherent in the pipeline. As one skilled in the art will know, the term "swapped out" refers to causing a process to relinquish storage and CPU access for other work for a period of time. To minimize the resources required to harden the data after, for example, processing by the RATER application, a pipe fitting according to the present invention is implemented. FIG. 12 depicts the flow associated with the Company X billing process implemented with an exemplary data hardening pipe fitting according to the present invention. Initially, as with FIG. 10, the data indicating services used is stored on a storage device (STEP 108, "STORE DATA ON STORAGE DEVICE"). The RATER application then opens the file containing the data, reads the data and calculates the charges (STEP 110, "READ DATA AND CALCULATE CHARGES"). As RATER is processing the data, it is transferred into a pipe for reading by the BILLER application (STEP 112, "CHARGES TO PIPE AS PROCESSED"). The output of RATER is passed from the pipe to a pipe fitting by the I/O control system (STEP 114, "CHARGES TO PIPE FITTING"). The pipe fitting hardens the data and returns it to the I/O control system for piping and reading by the BILLER application (STEP 116, "STORE CHARGES ON STORAGE DEVICE"; and STEP 118, "CHARGES BACK TO PIPE AS PROCESSED"). The I/O Control System has no awareness of the function of the pipe fitting. In this instance, the pipe fitting will write the record received to storage media (STEP 116) and the same record will be returned to the I/O control system by the pipe fitting for writing back to the pipe (STEP Concurrent with the RATER application processing the data and placing it in the pipe, and the pipe fitting hardening the data, the BILLER application reads the data placed back in the pipe by the I/O control system (STEP 120, "READ CHARGES FROM PIPE") and then formats the data for printing (STEP "FORMAT BILL"). After formatting the piped data, the BILLER application sends the formatted data into the output stream for subsequent printing (STEP 124, "PRINT BILL"). An exemplary JCL implementation of the flow diagram of FIG. 12 is given below:
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// SUBSYS=(BP01,`FIT=BPR .linevert split. QSAM HARDEN .linevert
split.
BPW`),
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
7.//HARDEN DD DSN=BILLING.DATA,
8.// DISP=(NEW,CATLG,),UNIT=TAPE,
VOL=SER= SAVEIT,
9.// LRECL=120,BLKSIZE=32760,RECFM=FB
10.//BILLER JOB
11.//STMT EXEC PGM=BILLER
12.//INPUT DD DSN=BILLING.DATA,
13.// SUBSYS=BP01,
14.// LRECL=120,BLKSIZE=32760,RECFM=FB
15.//OUTPUT DD SYSOUT=*
______________________________________
The I/O control system command on line 5 includes an embedded keyword subparameter (FIT=), which defines the pipe fitting. The pipe fitting includes a reference to a file defined by the statement named "HARDEN", the contents of which will be the output from RATER. Note that the pipename for the input to BILLER (i.e., "billing.data") does not have to change. The pipe fitting is specified entirely, in this case, as a subparameter for the SUBSYSTEM parameter on line 5. The "FIT" designation on line 5 indicates to the I/O control system that a pipe fitting specification follows, which is designated "BPR.linevert split.QSAM HARDEN.linevert split.BPW". Line 5 describes the pipe fitting and begins with "BPR", which represents a request to obtain a record from the I/O control system. Once obtained, the record is passed to the next function in the specification. The vertical bar ".linevert split." indicates the end of the first function, in this case, "BPR" and the beginning of the next function. The "QSAM HARDEN" portion of line 5 represents a request. for using a queued sequential access method (QSAM) to write a copy of the data to a file defined by a JCL statement labeled "HARDEN", which is specified on lines 7 through 9. If the QSAM stage command is first in the pipeline, the file will be read from; if specified at any other stage, the file will be written to. "BPW" represents a request for a return to the I/O control system with the data and/or a condition code representing action to be taken by the I/O control system. FIG. 13 is a topology diagram showing data flow between elements in an exemplary implementation of the flow diagram of FIG. 12. The data is accessed from a storage device 126 by the RATER application 128, which then processes the data and writes to a pipe 130 as the data is processed. However, before the processed data reaches pipe 130, it is routed to a pipe fitting 132. Recall that a pipe fitting is a special instance of an adapter that acts on data before it passes through a pipe. The pipe fitting is passed a pointer to the data and the length of the data. The pipe fitting writes the data to a storage device 134 to contain the hardened data and then returns to the I/O control system indicating the data to be written to the pipe 130 for reading by the BILLER application 136. Pipe fitting 132 is transparent to RATER, and executes under resources owned by RATER, since it is defined under the JCL defining the RATES job. The BILLER application reads the data from the pipe written by the I/O control system, formats the bill and writes the output to the data output stream for printing by a printer 138. As contrasted with FIG. 11, the use of a pipe fitting requires one less pipe, one less dispatchable unit of work, one less storage map (e.g. address space), and one less CPU for maximum parallelism. To maximize parallelism, the pipe fitting would preferably be placed on the connection which consumed the least CPU cycles per record. For maximum parallelism without consuming unnecessary resources, in this case, only two CPUs would preferably be used (i.e., one for RATER and its associated pipe fitting, and one for BILLER). The present invention significantly reduces the resources consumed in the process of hardening the data by accomplishing the function of the hardening job outside the confines of the applications in the pipeline. The function of the COPIER job is accomplished by a pipe fitting, which is a function that interfaces with an I/O control system for the purpose of acting on data placed in a pipe, for example, selecting, formatting, altering, combining with other data or hardening the data. The pipe fitting is independent of the applications in the pipeline, which allows the applications to remain unchanged, i.e., no coding changes to the applications in the pipeline are needed. Existing applications whose code is not desired to be modified, for example, code critical to the company or data processing site, will be referred to herein as "heritage applications". Assume now that Company X is hardening data to a special data set known as a generation data group data set. Use of a generation data group assumes there is a requirement to harden the data for auditing purposes. In the previous example, it was noted that a COPIER job is a successful, but resource-excessive means of hardening data. In the use of generation data groups, having an additional job in the pipeline to make a copy of the next level of the piped generation data group would not be a possible solution. Generation data group data sets have a common data set name prefix, but are differentiated by use of an index level as a member name. Level zero is the base data set, level +1 is generated from level zero and so on. If the "billing.data" file is actually a generation data group and RATER reads level 0 and pipes level 1, seeking to harden level 1, it is not possible to do so by adding an additional stage (i.e., the COPIER job) to the pipeline. The reason for this restriction is that COPIER would request exclusive use of the generation data group common prefix name while RATER would have the resource in shared mode to read the base level. COPIER would be denied the resource, thereby preserving data integrity of the generation data group. This request would result in a deadlock, and RATER and COPIER could not run as part of a pipeline as noted in FIG. 10 for hardening. Conventionally, hardening under these circumstances is only possible by application modification or adding a new and separate process to run after the pipeline, thereby requiring even more resources and time. The task can, however, be accomplished by implementing a pipe fitting as described in the previous example to harden the data placed in a pipe. The pipe fitting would be executed under the resources allocated by RATER and thus would be assigned exclusive use of the common prefix name of the generation data group. This example is an instance of how the present invention can be used to solve problems in pipeline construction that are introduced by operating system resource serialization requirements. Assume now that Company X accidentally overcharged another company, the Hal Company, and wishes to locate all the records associated with the Hal Company and rerun the billing process therefor. Assume also that the data relating to the Hal Company resides in columns 12-14 of the data records. Since the basic piping capability only transfers data between applications (or jobs) and/or storage devices, another job would, conventionally, be created to accomplish the selection of the data related to the Hal Company for the re-billing of the Hal Company by Company X. FIG. 14 depicts the flow associated with one example of the re-billing of the Hal Company by adding another job to the billing process. Initially, the data regarding the usage of Company X services is stored on a storage device (STEP 140, "STORE DATA ON STORAGE DEVICE"). The RATER application opens the file containing the data, reads the data and calculates charges (STEP 142, "READ DATA AND CALCULATE CHARGES"). As the RATER application is processing the data, it is transferred to a first pipe for reading by a record selection job named "SELECT" (STEP 144, "CHARGES TO PIPE 1 AS PROCESSED"). Concurrent with STEP 144, the SELECT job reads the output of the RATER application from the pipe (STEP 146, "READ CHARGES FROM PIPE 1") and excludes all records, except those relating to the Hal Company (STEP 148, "SELECT CHARGES"). The SELECT job then writes the Hal Company data to another pipe (STEP 150, "WRITE SELECTED CHARGES TO PIPE 2"). Concurrent with the transferring into the second pipe by the SELECT job, the BILLER application reads the selected data from the second pipe (STEP 152, "READ SELECTED CHARGES FROM PIPE 2"). After reading the data, the BILLER application formats the data and outputs the formatted data to the output stream for subsequent printing by a printer (STEP 154, "FORMAT AND PRINT BILL"). As can be appreciated from FIG. 14, the addition of the SELECT job consumes resources over the billing process implemented with a basic I/O control system. Specifically, an additional pipe and two connections therefor are required. Also, another initiator is required for the SELECT job, and there is additional overhead required for piping the data, and path length and data movement and/or data management costs are incurred. Further, the introduction of another application (i.e., "address space") results in additional contention for resources. If swapping is enabled, the SELECT job represents an additional candidate which could be swapped out and thereby diminish the effectiveness of the concurrent execution inherent in the pipeline. The present invention significantly reduces the resources consumed in the process of rebilling the Hal Company by accomplishing the function of the SELECT job outside the confines of the original pipeline. The function of the SELECT job is accomplished by a pipe fitting. The ability to specify the selection in the pipe fitting enables less data to be piped than if the SELECT job were to be used. It also enables application programs a quick methodology to develop perhaps a single use application without having to use the "compile, assemble and link edit" process necessary for stored library programs in higher level languages, since the data adapters are specified in an interpreted language which goes directly to machine instruction level at the time of execution and only for the path executed. One skilled in the art will understand the "compile, assemble and link edit" process. Preferably, an interpreted language known as "CMS Pipelines" is used, however, other interpreted languages may be used, such as, for example, REXX (Restructured Extended Executor Language) and APL (A Programming Language). Use of the pipe fitting also allows the heritage applications to remain unchanged. An interpreted language is generally a language for decoding and immediately executing instructions written as pseudo-code. In order to use an interpreted language to define an adapter according to the present invention, an interface between an interpreted language and the particular environment (e.g., CMS, MVS) is needed. A preferred programming interface method allowing the use of an interpreted language to define an adapter, will now be described. In order to implement a data adapter, the I/O control system or an access method, and data adapter implementation language must be "connected." At device allocation time, the presence of the adapter is flagged in a communication area in memory for the adapter and the operating system components. The communication area could exist, for example, in virtual storage. The adapter specification and/or an indication of its location is also saved in the communication area. At access method data set open time, the indication of adapter presence triggers the invocation of a language parser, and the location of the adapter specification is passed thereto. A language parser reviews a language statement to confirm that it is syntactically and structurally correct for the particular language being used. The language parser is part of that language, and may be housed therewith. The language specification of the adapter is read into memory, and the parser returns an indication of success or failure of language specification recognition. If success is indicated, the parser returns a token representing the instance of the language specification. If failure is indicated, OPEN processing terminates abnormally. When data is available in the I/O control system, the adapter begins to execute on the first instance of data presence. Subsequent data availability results in resumption of adapter execution. At access method data set close time, the access method close process must invoke the language routines with an indication that it is the last resumption of adapter execution. The language routines then return an indication of success or failure of the last adapter resumption and completion thereof. If failure is indicated, CLOSE processing terminates abnormally. Extensions to a given interpreted language (i.e., the addition of new language constructs) may or may not be necessary to implement the adapter for a particular operating system. In addition, extensions to the operating system itself may or may not be necessary to implement the adapter. FIG. 15 is a flow diagram for the Hal Company rebilling process implementing a pipe fitting in accordance with the present invention. Initially, the data indicating services used by customers is stored on a storage device (STEP 156, "STORE DATA ON STORAGE DEVICE"). The RATER application accesses the data and processes it (STEP 158, "READ DATA AND CALCULATE CHARGES"). The RATER application writes charges to the pipe as they are calculated (STEP 160, "CHARGES TO PIPE AS PROCESSED"). A pipe fitting is invoked out of the I/O control system to select the data to be piped for reading by the next stage in the pipeline (STEP 162, "SELECT DATA TO BE PIPED"). The function of the pipe fitting is similar to that performed by the SELECT job described with respect to FIG. 10, however, no additional pipe is needed between the RATER application and the pipe fitting. As the pipe fitting is selecting the Hal Company data from the output of the RATER application, the Hal Company data is passed by the pipe fitting back to the I/O control system for transfer to the pipe and reading by the BILLER application (STEP 164, "READ SELECTED CHARGES FROM PIPE AS PROCESSED"). Concurrently with the pipe fitting passing the Hal Company data to the pipe, the BILLER application reads the Hal Company data from the pipe and formats it (STEP 166, "FORMAT BILL"). After the BILLER application formats the selected charges into a bill, it is sent to the output stream for subsequent printing (STEP 168, "PRINT BILL"). An exemplary JCL implementation of the flow diagram of FIG. 15 is shown below, and replaces the RATES job of the JCL program described with reference to FIG. 13, with the rest being the same.
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// SUBSYS=(BP01,`FITDD=FITTING`),
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
7.//FITTING DD *
8. BPR .linevert split. locate 12-14 /HAL/ .linevert split. BPW
______________________________________
The operation of the above program portion is similar to that of the RATES job described with respect to FIG. 9, except that the pipe allocation specification on line 5 indicates that the pipe fitting can be found in a file defined on the JCL statement labelled"FITTING". The "FITTING DD *" on line 7 is JCL indicating that the pipe fitting is defined in a file and the contents of the file are specified on line 8 of the JCL program. Line 8 describes the pipe fitting and begins with "BPR". BPR represents a request to obtain a record from the I/O control system. The data obtained is passed to the next function which is the "Locate 12-14/HAL/" portion of line 8 and represents a request for locating, in columns 12-14, all data for the Hal Company. If the word "HAL" is located in the record, the record is selected to be passed to the next function, which is "BPW". The "BPW" portion of line 8 indicates a request to place data in the pipe, and is also a request to return to the I/O control system with the record and/or a condition code representing action to be taken by the I/O control system. An alternative programming approach for accessing the pipe fitting described with respect to FIG. 15 is presented below.
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.USAGE,DISP=OLD
4.//OUTPUT DD DSN=BILLING.DATA,
5.// SUBSYS=(BP01,`FIT=BPR .linevert split. locate 12-14/HAL/ .linevert
split.
BPW`),
6.// LRECL=120,BLKSIZE=32760,RECFM=FB
______________________________________
The above alternate approach avoids the overhead of data set allocation, unallocation, and the open and close processing of a file containing the pipe fitting specification. However, this alternative approach becomes less practical as the size of the fitting specification becomes larger; in fact, limitations on the maximum parameter size in the JCL naturally bound the size of the fitting specification. Use of the "FITDD" keyword is preferred over the "FIT" keyword for fitting specifications exceeding a few lines. FIG. 16 is a topology diagram showing data flow between elements in an exemplary implementation of the flow diagram of FIG. 15. The data indicating services used by customers is accessed from a storage device 170 by the RATER application 172, which calculates the customer charges and writes the charges to a pipe 174 as they are processed. However, prior to reaching pipe 174, the processed data is routed to a pipe fitting 176 by the I/O control system, which transfers the data to, and invokes pipe fitting 176. The pipe fitting acts on the data by selecting only the Hal Company data and returning it to the I/O control system, which writes it to pipe 174 for reading by the BILLER application 178. Pipe fitting 176 is transparent to RATER, and executes under resources owned thereby, since it is defined under the JCL defining the RATES job. Concurrent with RATER processing data and pipe fitting 176 selecting and returning selected data to pipe 174, the BILLER application reads the selected data placed back in pipe 174, formats the bill and sends it into the data stream for subsequent printing by a printer 180. A more efficient and preferred usage of the pipe fitting of FIG. 15 would be to logically place it prior to the RATER application, if possible, so that only the Hal Company data is processed by the RATER application. In this way, the data is preprocessed prior to accessing by the RATER application. FIG. 17 depicts one example of the flow associated with the Hal Company rebilling process according to the present invention where the data is preprocessed prior to invocation of the RATER application. Initially, the data indicating services used by Company X customers is stored on a storage device (STEP 182, "STORE DATA ON STORAGE DEVICE"). A source/sink adapter reads the data from the selected data source, selects out only the Hal Company data (STEP 184, "READ AND SELECT DATA"), and passes it to the RATER application for processing (STEP 186, "READ SELECTED DATA AND CALCULATE CHARGES"). In this example, the source/sink adapter employs the I/O control system to obtain data from the device using access method macros. However, when a data source/sink is not a device, the source/sink adapter need not use access methods or the I/O control system. As the charges are being calculated by the RATER application, they are passed to a pipe (STEP 188, "WRITE CHARGES TO PIPE AS PROCESSED"). Concurrent with the RATER application passing processed data into the pipe, the BILLER application reads the data from the pipe (STEP 190, "READ SELECTED CHARGES FROM PIPE"), formats it (STEP 192, "FORMAT BILL"), and sends it into the data stream for subsequent printing (STEP 194, "PRINT BILL"). An exemplary JCL program implementation of the flow diagram of FIG. 17 is presented below.
______________________________________
1.//RATES JOB
2.//CALC EXEC PGM=RATER
3.//INPUT DD DSN=CUSTOMER.HAL,
4.// SUBSYS=(BP01,`FITDD=FITTING`,OPENNOW),
5.// LRECL=120,BLKSIZE=32760,RECFM=FB
6.//OUTPUT DD DSN=BILLING.DATA,
7.// SUBSYS=BP01,
8.// LRECL=120,BLKSIZE=32760,RECFM=FB
9.//DATAIN DD DSN=CUSTOMER.USAGE,DISP=OLD
10.//FITTING DD *
11. QSAM DATAIN .linevert split. locate 12-14 /HAL/ .linevert split. BPW
12./*
13.//BILLER JOB
14.//STMT EXEC PGM=BILLER
15.//INPUT DD DSN=BILLING.DATA,
16.// SUBSYS=BP01,
17.// LRECL=120,BLKSIZE=32760,RECFM=FB
18.//OUTPUT DD SYSOUT=*
______________________________________
Line 3 opens a preprocessing "half-pipe" named "customer.hal" for data going into the RATER program. The "OPENNOW" sub-parameter on line 4 of the program is used to override the BatchPipes.TM. system standard operation of waiting in an open state until there is an incidence of a writer-reader pair for the pipe. However, in this case, there is no writer to the pipe (it is a half-pipe), therefore, the user should not wait in the open state. On line 11, the source/sink adapter specification begins with "QSAM DATAIN", which indicates that the file defined by the JCL statement labeled "DATAIN" should be read at this point. The contents of the DATAIN file, the customer usage data on a storage device, are found on line 9 of the program. The source/sink adapter specification in this case is a bit more complicated, since a half-pipe is existing with a reader and no writer. This implementation of the source/sink adapter is more efficient than the pipe fitting used in FIG. 15, since the RATER application only calculates charges for the selected company, rather than for all companies. FIG. 18 is a topology diagram showing data flow between the elements of an exemplary implementation of the flow diagram of FIG. 17. Assume that the RATER application has targeted some media 195 other than storage device 196 for data on which to calculate charges for services used by customers. The data indicating services used is actually accessed from storage device 196 by a source/sink adapter 198 through a half-pipe (not shown, since no physical FIFO buffer corresponds-thereto) having source/sink adapter 198 as a reader. The source/sink adapter sorts out all the Hal Company data and passes it to the RATER application 200. Source/sink adapter 198 is transparent to RATER, and executes under resources owned thereby, as indicated by the fact that it is defined in the JCL for the RATES job. The RATER application reads the Hal Company data and calculates the charges therefor. As the RATER application 200 calculates the charges, it writes them to a pipe 202 for concurrent reading by the BILLER application 204, which formats the Hal Company charges into a bill, and sends the bill into the data stream for subsequent printing by a printer 206. As described herein, the present invention comprises a method and apparatus for acting on data in a process via an internal operating system interface from an I/O control system while refraining from adding any new applications to the process or making any coding changes to heritage applications. The event in the case of an adapter is an application request to read or write data. The data is acted on via an adapter which operates outside the application, requiring significantly less resources than the addition of another application to act on the data. While several aspects of the present invention have been described and depicted herein, alternative aspects may be effected by those skilled in the art to accomplish the same objectives. As one example, other coding languages could be used to implement an adapter. Accordingly, it is intended by the appended claims to cover all such alternative aspects as fall within the true spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||