|
midrange.com
An API on the CRTDTAQ should never be called when the data queue is used.
If you are thinking of the command api recently, (and still being), batted
around on this list.
Sounds to me like you want to be able to CRTDTAQ and have the applications
program think they are writing to a remote data queue, but then an API
program would take this pseudo data queue and use some IP function (sockets
perhaps) to update a data queue on a remote system. This is something I
think should be IBM written and supported.
This pseudo program could be written now by using a local data queue on the
remote system. Have your sockets program process that data queue and send
it to the remote data queue. I just want to avoid sockets and stick with
data queues.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"Steve Richter"
<srichter@AutoCoder To: <midrange-l@midrange.com>
.com> cc:
Sent by: Subject: Re: Remote Data
Queues Over TCP (was Re: Most efficient
midrange-l-admin@mi AS400 physicalfile building
?)
drange.com
08/10/2001 11:09 AM
Please respond to
midrange-l
Some openness from ibm and this rmt dtaq over ip shortcoming could be
resolved.
Add an exit pgm to the CrtDtaq cmd. If spcfd, the exit pgm would be called
by the system when sending or receiving from the dtaq. The exit pgm would
be
responsible for the actual sending or receiving of the data.
This would enable:
1. access to a dtaq on a remote system thru a tcp/ip connection.
2. send and receive data on any system, remote or local, as400 or non
as400.
3. receive data/messages from multiple sources: user pgm receives from the
dtaq, the exit pgm is called, exit pgm polls multiple systems for the data,
polls for msgs from a msgq, data is returned with an extended sender fld
that contains the identity of the source of the data.
Steve Richter
-----Original Message-----
From: rob@dekko.com <rob@dekko.com>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Date: Friday, August 10, 2001 11:29 AM
Subject: Re: Remote Data Queues Over TCP (was Re: Most efficient AS400
physicalfile building ?)
>
>Well, I want to avoid the SNA over TCP approach.
>
>I can't figure out how to create a data queue to use TCP. For example
when
>I use CRTDTAQ TYPE(*DDM) then I get all sorts of SNA prompts but no TCP.
>However if I do a CRTDDMF RMTLOCNAME(remotehost *IP) instead of the
>default of *SNA I get IP type prompts instead.
>
>Rob Berendt
>
>==================
>A smart person learns from their mistakes,
>but a wise person learns from OTHER peoples mistakes.
>
>
>
> thomas@inorbit.com
> Sent by: To:
MIDRANGE-L@midrange.com
> owner-midrange-l@mi cc:
> drange.com Subject: Re: Remote Data
Queues Over TCP (was Re: Most efficient
> AS400 physical file
building ?)
>
> 08/09/2001 05:37 PM
> Please respond to
> MIDRANGE-L
>
>
>
>
>
>
>I am aware of two ways to get *dtaq support via TCP/IP in a more or less
>IBM-supported fashion.
>
>First, SNA over TCP/IP. That's the obvious answer.
>
>But second, one of the host servers is a *dtaq server. Although designed
to
>speak with Client Access, it can be talked with via Java from a client app
>on a PC. The biggest trick seems to me to be getting the connection handle
>out of the signon server. (Example of a smaller trick is apparently that
>these host servers want to talk ASCII.)
>
>However, given that the OS/400 JVM is certified for pure Java and the Java
>toolkit used for client apps is supposed to be available for platforms
that
>support pure Java...?
>
>In any case, if you can get a connection handle, the rest should be a
SMOP,
>Java or no Java. No?
>
>Tom Liotta
>
>On Thu, 09 August 2001, Evan Harris wrote:
>
>> I'm sure I recall making remote data queues work over TCP. What problems
>> did you have ?
>>
>> <SNIP>
>>
>> >The biggest problem I have with data queues is that they are sna only.
>DDM
>> >files can be either the default of sna, or the better performing tcp.
>You
>> >still have this limitation under V5R1. Maybe it is time to evaluate
>> >sockets. I wish IBM would embrace TCP for data queue support! (I
would
>> >put more exclamation points but some email filters would trash it.)
>
>--
>Tom Liotta
>The PowerTech Group, Inc.
>19426 68th Avenue South
>Kent, WA 98032
>Phone 253-872-7788
>Fax 253-872-7904
>http://www.400Security.com
>
>
>___________________________________________________
>The ALL NEW CS2000 from CompuServe
> Better! Faster! More Powerful!
> 250 FREE hours! Sign-on Now!
> http://www.compuserve.com/trycsrv/cs2000/webmail/
>
>
>
>
>+---
>| 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
>+---
>
>
>
>
>_______________________________________________
>MIDRANGE-L mailing list
>MIDRANGE-L@midrange.com
>http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>
_______________________________________________
MIDRANGE-L mailing list
MIDRANGE-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/midrange-l
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.
