|
Hello Chris, There are a number of possibilities when communicating between programs and jobs. Programs can share storage via a mechanism like global variables or by passing parameters. They can also use an external object. Jobs (or separate processes) cannot easily share the same storage and need to use an external object. The choices of object can be: 1/ Data area 2/ Database file 3/ Message queue 4/ User queue 5/ Use space 6/ User index Data areas are sloppy because they cause a synchronous disk I/O for every access therefore causing a performance hit. They can also hold only a single value at a time -- by that I am not referring to defining the data area as a structure, but that a given field in the data area can only hold a single value (e.g., next invoice number) and so forces synchronous access. A control file is more efficient for this sort of thing avoiding a programmatic lock/unlock protocol. Database files are good if you need persistence. They are fast enough for random access but if you are trying to build a stack of tasks they are inefficient. For example, assumme a number of interactive jobs are scheduling work for a never-ending batch process. Each interactive job writes a record to the file which the batch job is waiting for. How does the batch job wait? It either delays for a period of time of waits on EOF. Both methods are a form of polling in that the job does no work while it is waiting and if a record arrives during the wait the batch job doesn't know about it until the wait completes. Even if no records arrive during the wait, the job still has to check the file thus consuming CPU for no real work. Message queues are faster than a file and are an event driven process but don't have persistence. The contents of the queue are not saved so queues should not be used for permanent data. They must be accessed with CL commands or the message handler APIs. CL is slow, and while the MH APIs are not difficult, they are more complex than some of the alternatives. However, they are more efficient than either of the two previous options because the waiting job can sleep until a message arrives thus using no CPU until work is actually required. Data queues are faster still primarily because the I/O doesn't involve a disk access, also are event driven (thus having the advantages of the MSGQ), also don't have persistence, but are simple to use because the major work is done by the QSNDDTAQ (send Data Queue) and QRCVDTAQ (Receive Data Queue) APIs. Because work can be queued, the sender and receiver can operate asynchronously. User queues are faster again but you have to use the ENQ and DEQ MI instructions (or the C built-in equivalents) to access the queue because there are no APIs to send and receive messages to user queues. User spaces can also be used where more data is required than a queue will support but there is no event process so we're back to polling or using a combination of objects (e.g. send data to space, send entry to queue telling batch job to process the space). Access is via the user space APIs. User indices are good where large amounts of keyed data are required and are generally used in conjunction with a space object. Again there is no event process so polling is required to check for new index entries, but a queue could be used in conjunction with an index as described above. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»« »«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
IME-Version: 1.0 Date: Tue, 18 Jan 2000 18:37:20 +0000 From: Chris.Chambers@v2music.com To: COBOL400-L@midrange.com Reply-To: COBOL400-L@midrange.com Subject: Program-to-program communication (Was DTAARA in COBOL)
K Simon, This is where I become a real pain - I understand the call of a COBOL program using parameters as described in the first part of your reply but the second bit loses me. This is mainly because I have not used data queus before - how are they more efficient than a data area. Cheers, Chris "Simon Coulter" <shc@flybynight.com.au> on 14/01/2000 21:44:54 Please respond to COBOL400-L@midrange.com To: COBOL400-L@midrange.com cc: (bcc: Chris Chambers/London/V2 Music) Subject: Re: Program-to-program communication (Was DTAARA in COBOL)
Hello Chris, Yes. Linkage section. Used to communicate synchronously by defining parameters and issuing a CALL ... USING ... Also used to communicate asynchronously by linking to the QSNDDTAQ and QRCVDTAQ APIs and then issuing a CALL ... USING ... to send the data to a data queue. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
IME-Version: 1.0 Date: Thu, 13 Jan 2000 12:54:29 +0000 From: Chris.Chambers@v2music.com To: COBOL400-L@midrange.com Reply-To: COBOL400-L@midrange.com Subject: Program-to-program communication (Was DTAARA in COBOL) imon, Are we talking linkage section here? If not could you expand a little. Thanks for the help so far, Chris "Simon Coulter" <shc@flybynight.com.au> on 12/01/2000 20:43:39 Please respond to COBOL400-L@midrange.com To: COBOL400-L@midrange.com cc: (bcc: Chris Chambers/London/V2 Music) Subject: Program-to-program communication (Was DTAARA in COBOL)
F Hello Chris, Simple. The problem with data areas is the obscurity -- especially the LDA. Synchronous communication is best performed by passing parameters. Asynchronous communication is best performed using queues. There are other techniques available but those are the most straight-forward. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» +--- | This is the COBOL/400 Mailing List! | To submit a new message, send your mail to COBOL400-L@midrange.com. | To subscribe to this list send email to COBOL400-L-SUB@midrange.com. | To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---END
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.