Re: Remote Data Queues Over TCP (was Re: Most efficient AS400 physicalfile building ?)

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
>