Re: Program-to-program communication (Was DTAARA in COBOL)

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

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