× 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.




     Hmmm, I see the following in Intrasystem Communications Programmer 
     Guide (Appendix C1 - Using Intrasystem Communications for APPC):
     
     "Evoke Function -- When your program uses the evoke function to 
     start another program and you specify *USER for the user ID on the 
     SECURITY keyword, intrasystem communications always passes the user 
     ID on the program start request.  However, APPC only passes the 
     user ID if the remote system accepts a user ID that has already 
     been verified."
     
     It seems ICF normally requires EVOKE, with a few exceptions: BSCEL 
     and SNUF. 
     
     I should have done more research before responding........ :(
     
     Eric DeLong


______________________________ Reply Separator _________________________________
Subject: Re: ICF Programming Snafu's! I Don't want to EVOKE! 
Author:  <MIDRANGE-L@midrange.com > at INET_WACO
Date:    10/14/98 6:41 PM


Eric,
This is using a SDLC communication, and that seems to be the diffeence in the 
original way they were doing this.  So far, the answers I've found say that 
EVOKE is needed for this.  Now I'm stuck - I don't want to hardcode the 
security parms into the SECURITY parm in the ICF file, and I may have to 
internally describe this portion of the communications.  I'm confused!  It 
looks like it can be done, yet it can't!
-Andrew
     
     
Date: Wed, 14 Oct 98 14:30:05 -0600
From: eric.delong@pmsi-services.com
Subject: Re: ICF Programming Snafu's! I Don't want to EVOKE!
     
     Andrew,
     
     I'm not exactly sure I understand.... is it something like:
     
     1> AS400 (sys a) always runs a comm job that just waits for 
     connection (ICFW or BSCW).
     
     2> AS400 (sys b) dialing into sysA for testing. As soon as 
     connection is established, pgms start talking.
     
     3> Tandem (sys c) dialing in to sysA for production. like above.
     
     
     A waiting for connection
     B or C dialing A
     Connect
     B-->A  (send request) pgm to pgm
     A-->B  (send reply)   pgm to pgm
     Disconnect
     A waiting for connection
     
     Evoke is not necessary. Just have the comm job active on Sys A, and 
     it will just wait for a valid connection to begin. If this is the 
     scenario, I might be able to provide you with samples. Contact me @
     
     eric.delong@pmsi-services.com
     
     
______________________________ Reply Separator 
_________________________________
     
Andrew Borts wrote:
     
> I'm trying to simulate connection to a mainframe via an ICF file using 
> two AS/400's , and I'm running into a problem in getting the two AS/400 
> to chat with one another.  I want to blind transmit information sent
> over the ICF to the receiving AS/400 end, and reply using the program 
> that is sitting and waiting for a communication that would normally be
> to a mainframe (tandom..).  So far, I've run into the snafu that I have 
> to evoke the receiving end from the transmitting AS/400 end.  In
> reality, I don't want to evoke, and I want the other end just to
> startup, and answer messages sent by the mainframe.  Any clues as to 
> what I do?
> -Andrew Borts
> Systematic Control, Inc.
> (954) 791-9555 x333
>
>   ------------------------------------------------------------------------ 
>
>   Andrew Borts <adborts@ibm.net>
>   Systematic Control, Inc.
>
>   Andrew Borts
>   Systematic Control, Inc.  <adborts@ibm.net>
>                             Netscape Conference Address
>                             Netscape Conference DLS Server 
>   Additional Information:
>   Last Name     Borts
>   First Name    Andrew
>   Version       2.1


+---
| 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.