× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Convert an LU6.2 program to use *DTAQ's
  • From: Chris Bipes <ChrisB@xxxxxxxxxxxxxxx>
  • Date: Mon, 9 Aug 1999 09:41:52 -0700

Data queues are very fast for program to program transfer of data.  They
also let several jobs dump data to be processed by one or more background
programs.  To use data queues from system to system, you have to have an SNA
connections.  You then define a local data queue on system A and a remote
data queue on system B pointing to the data queue on system A.  The Os
creates a ddm connection from system be to system A using SNA.  If your Unix
box is defined and connected to your AS400 via SNA this will work.  The
advantage is the Os gets the data from one system to the other and not the
applications.  The application just has to handle the error on the QSNDDTAQ
API.  This allows for multiple jobs to send data to a remote system and not
worry about communications.  How ever the connection is much slower that
LU62.  I use a mixture of the two.  ICF, (LU62), where I have large volume
of transactions and Remote Data Queues for used functions.
 
Hope this helps.
 
Christopher K. Bipes      mailto:ChrisB@Cross-Check.com
<mailto:ChrisB@Cross-Check.com>  
Sr.. Programmer/Analyst          mailto:Chris_Bipes@Yahoo.com
<mailto:Chris_Bipes@Yahoo.com>  
CrossCheck, Inc.              http://www.cross-check.com
<http://www.cross-check.com/>  
6119 State Farm Drive         Phone: 707 586-0551 x 1102 
Rohnert Park  CA  94928Fax: 707 586-1884 

-----Original Message-----
From: Tim Truax [mailto:truax@usaor.net]
Sent: Saturday, August 07, 1999 6:06 PM
To: MIDRANGE-L list
Subject: Convert an LU6.2 program to use *DTAQ's


Hello all,

Here's the scenario: 

2 computers.

*       (A)-UNIX box 

*       (B)-AS400 box

2 abbreviations.

*       RFI-request for information 

*       IRF-information request fulfillment

(A) supplies the WEB page from which the RFI is sent to (B) which responds
with the IRF. Currently the mode of communication between (A) and (B) is via
an LU6.2 RPG communication program using an ICF file. (A) sends RFI to (B),
then (B) retrieves from its database this IRF and sends it back to (A) which
displays a web page with the IRF. I have been delegated the exciting task of
replacing this RPG communication program using the ICF file on (B) with a
dual *DTAQ scenario, 1 data queue to receive the RFI and 1 data queue where
the IRF will be placed. The people that run (A) have told me they've written
a JAVA program that can read a *DTAQ on (B), that being said, my thinking is
that it should be a rather simple matter for me to strip out the uses of the
ICF file from the RPG communication program which runs on (B) and simply
slip in the dual *DTAQ's as the objects I use to read the RFI placed there
by (A) and then populate the IRF to the other *DTAQ on (B) and then (A) will
read it.

Is my thinking feasible, if not please offer suggestions?

Will this be more efficient that LU6.2?

Is there any advice that you can offer me on doing this?

:-) Tim & Dana Truax ... and Caleb :-)
http://members.xoom.com/truax <http://members.xoom.com/truax> 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.