Hmm, I remember looking over Steve Shreeve's shoulder as we tried various tricks to work around the non-routeable callback problem. As you see the client can signal that it doesn't want to be called back (requires modifying the client broker to use "^"-piece 5 of the message), or the server can decide not to call back, based on the $$GETPEER return. But if a "reject" is returned to the client at this point the listener must have fallen through to standard callback mode. To the best of my knowledge these circumventions were eventually abandoned in favor of tunneling the callback. I don't have a copy of this version or of the ^ZUTL routine. However, you should see where the log is stored by looking in ^ZUTL.

Lloyd


----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 20, 2004 9:26 AM
Subject: Re: [Hardhats-members] CPRS connection problems



Lloyd,

Thanks.  I saw your name in the code, so I know you
hve knowledge in this area.

Also, I see the command LOG^ZUTIL("...")  How do I
read these log files/entries?

I'm hoping you have some input on my other post too.
:-)
Thanks
Kevin



--- Lloyd Milligan <[EMAIL PROTECTED]> wrote:

Kevin, In that second block of code, the "reject"
reply is sent when the
attempt to JOB EN^XWBTCPC(parameter_list) fails
(timeout=5 sec).  Failure is
also recorded under ^TMP("TCP").   Thus, zwrite
^TMP("TCP") should confirm
or disconfirm failure at this point.  Clearly this
is debug code.  However,
it could help in troubleshooting the problem.


Lloyd


----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 19, 2004 9:22 PM
Subject: Re: [Hardhats-members] CPRS connection
problems



> Lloyd, > > I get back a 1 when I "WRITE $$NEWJOB^XWBTCPL". > > Looking at the code for XWBTCPL, there are two ways > that "reject" gets sent back. You already brought up > the first way, and since I am getting back a 1, I > don't think this one is the problem. Below is the > relevent portion of code. The 2nd 'reject' is down at > the bottom. > > From tracing on the CPRS side, I think that MSG will > be: > "TCPconnect^192.168.3.4^1725^E-Machine^" > > > . I $P(MSG,"^")="TCPconnect" D > . . ;-- decrypt token > . . N DZ,%T > . . S DZ="",%T=0 > . . S RETRY=$S($G(RETRY)>1:RETRY-1,1:0) ;(*p7*) > . . I '$$NEWJOB D SNDERR W "reject",$C(4) D FLUSH > Q;(*p7*) > . . ; > . . ;Use "no callback" mode if client requests it or > is running NAT > . . S NOCB=0 > . . I $P(MSG,"^",5)'="" S NOCB=1 > . . ;#SGS# S NATIP=$$GETPEER^%ZOSV I > $L(NATIP),NATIP'=$P(MSG,"^",2) S > $P(MSG,"^",2)=NATIP,NOCB=1 > . . ; > . . ;Job a Server, X should be null > . . I NOCB D ;use "no callback" mode > . . . D LOG^ZUTIL("Entering 'no callback' mode") > . . . J >

EN^XWBTCPS($P(MSG,"^",2),$P(MSG,"^",3),$P(DZ,"^"),XWBVER,$P(MSG,"^",4))::5
> S %T=$T
>  . . . N PORT S PORT=$$SLOPPY S:PORT="" %T=0
>  . . . D LOG^ZUTIL("Slave port was '"_PORT_"'")
>  . . . I %T D SNDERR W "accept^"_PORT,$C(4) D
FLUSH
>  . . E  D  ;use "normal" callback mode
>  . . . D LOG^ZUTIL("Entering 'callback' mode")
>  . . . J
>

EN^XWBTCPC($P(MSG,"^",2),$P(MSG,"^",3),$P(DZ,"^"),XWBVER,$P(MSG,"^",4))::5
> S %T=$T
>  . . . I %T D SNDERR W "accept",$C(4) D FLUSH
>  . . I '%T D SNDERR W "reject",$C(4) D FLUSH S
> ^TMP("TCP",$P($H,",",2))="REJECT"
>  . ;
>
> So to pick apart the code, we have:
>  . . . J
>

EN^XWBTCPC($P(MSG,"^",2),$P(MSG,"^",3),$P(DZ,"^"),XWBVER,$P(MSG,"^",4))::5
> S %T=$T
> Which should become (with variable substitution)
>  . . . J
>

EN^XWBTCPC("192.168.3.4","1725","",XWBVER,"E-Machine")::5
> S %T=$T
>
> Then, looking at EN^XWBTCPC, I find one intersting
> line:
> ;Use Kernel to open the connection back to the
client
> on new port
> D CALL^%ZISTCP(XWBTIP,XWBTSKT) Q:POP S
> XWBTDEV=IO,IO(0)=IO
>
> Here is appears that the server tries to call back
to
> the client on the specified port... in this case
port
> "1725"
>
> There was a discussion a month or so ago about
> communications taking place using a random
callback
> port. It seems like this is the place that
happens.
> I looks like CPRS specifies what port it wants
call
> back on (and it looks like there is an option for
'no
> call back'). I'll have to look on the CPRS side
to
> see how the "1725" gets chosen.
>
> So I've followed this path about as far as I can
> tonight. I want to follow Nancy's suggestions and
see
> if there is a Windows Internet Connection Firewall
> blocking communication, and I want to try flushing
> (temporarily) my iptables on linux to see if that
> helps.
>
> Any input on any of this would be appreciated!
>
> Kevin
>
>
>
>
> --- Lloyd Milligan <[EMAIL PROTECTED]> wrote:
>
>> Kevin, Yes, that looks okay. I should have said
>> ","-piece, not "^"-piece.
>> But your names agree so that isn't it. I don't
>> immediately see where else
>> it could be. Can you try it manually? SET
>> XWBVOL="VOL" (your volume name).
>> Then WRITE $$NEWJOB^XWBTCPL. This should display
>> '1' if a new job can
>> start. If it returns '1' then we have to look
>> elsewhere for the trouble.
>> If it returns '0' then the problem is to figure
out
>> why. Possibly
>> ^%ZOSF("ACTJ") returns a bad value..
>>
>> Lloyd
>>
>> ----- Original Message ----- >> From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Sunday, December 19, 2004 7:39 PM
>> Subject: Re: [Hardhats-members] CPRS connection
>> problems
>>
>>
>> > Llyod,
>> >
>> > Thanks for your feedback. Here is a screen log
of
>> > when I check these things. All seems in order.
>> >
>> > If you or anyone else would be willing to
connect
>> to
>> > my machine, I could give connection
information.
>> >
>> > Thanks again
>> > Kevin
>> >
>> >
>> > GTM>x ^%ZOSF("UCI")
>> > GTM>w Y
>> > UCI,VOL
>> > GTM>d ^XUP
>> > -snip-
>> > Select VA FileMan Option: enter or Edit File
>> Entries
>> > INPUT TO WHAT FILE: kernEL SYSTEM PARAMETERS
(1
>> > entry)
>> > EDIT WHICH FIELD: ALL// volUME SET
(multiple)
>> > EDIT WHICH VOLUME SET SUB-FIELD: ALL//
>> > THEN EDIT FIELD:
>> >
>> > Select KERNEL SYSTEM PARAMETERS DOMAIN NAME: ?
>> > Answer with KERNEL SYSTEM PARAMETERS NUMBER,
or
>> > DOMAIN NAME:
>> > 1 TMEDGROUP.COM
>> >
>> > You may enter a new KERNEL SYSTEM PARAMETERS,
if
>> you


=== message truncated ===




__________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250


------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to