Gateway Less - Need Help
Thomas Rundo
running apps or ISQL and not getting correct data back.
Gateway is eliminated and the RPC handler is turned-on.
We have 3 RPC's that are not working correctly:
UNIX BOX CSTCIS01
1st after the RPC is called and complete we get an error message. "7224 -
Unexpected end-of-message encountered in RPC response from site..."
cics log shows
SYBASE 17:02:07.TRANID SYCH.TSKNO 00711... SEND MACRO HAS DIED WITH
ERRNO=0000277C......................................
SYBASE 17:02:07.TRANID SYCH.TSKNO 00711... CLOSE MACRO HAS DIED WITH
ERRNO=0000277C.....................................
UNIX BOX CSTDEV01
2nd we have 2 RPC's (fix one the other will fix itself) that are suppose to
return the row and the argument (parameter). It only returns the row. We
have to have both just how it works in production with the gateway on.
If we have the Gateway Eliminated and the RPC turned-off then the RPC's
(procedures) hang at execution.
If we have the Gateway NOT Eliminated and the RPC turned-off then everything
works (just as production).
Any help would be beneficial.
Thanks,
Tom
Mark K
What version of MainframeConnect and Open ServerConnect?
What is the server class for the remote server in ASE? (It should be
direct_connect).
You would want "cis rpc handling" set to 1. If you have a CICS
Troubleshooting guide handy, you can lookup the ERRNO and see what that
tells you. Also, be sure the CSPs are installed on the mainframe.
Mark Kusma
"Thomas Rundo" <tru...@a-asoftwaresolutions.com> wrote in message
news:45c9063c@forums-1-dub...
Thomas Rundo
Open ServerConnect is 12.50.06
It is Direct Connect
From our Mainframe Guys...
The return codes from our CICS unit test system. The RC=0 was when we went
threetier through the Gateway server. The RC=-173 was twotier going directly
to CICS. The only thing different between these 2 runs was settin RPC to ON
and changing the interfaces file to point to CICS in our DEV1CRS box.
Since both cases were running in the SAME CICS region and the only
difference being SNA connection verses the TCP/IP connection.
We believe
We believe we have fix the first issue (an extra call to send which the
Gateway did not care about), but still have a remaining issue. This
pertains to everything above.
UNIX BOX CSTDEV01
2nd we have 2 RPC's (fix one the other will fix itself) that are suppose
to return the row and the argument (parameter). It only returns the row.
We have to have both just how it works in production with the gateway on.
If we have the Gateway Eliminated and the RPC turned-off then the RPC's
(procedures) hang at execution.
If we have the Gateway NOT Eliminated and the RPC turned-off then
everything works (just as production).>>
Any help would be beneficial.
Thanks,
Tom
"Mark K" <xxxx> wrote in message news:45c940c6$1@forums-1-dub...
Thomas Rundo
declare @new_order char(10)
exec p_ppw_z001_next_order 'T',@new_order output
THIS IS THE ACTUAL PROCEDURE
CREATE PROCEDURE p_ppw_z001_next_order
(@arg_run_cv char(1),
@new_order char(10) output)
as
select @new_order = "0"
if @arg_run_cv = 'T'
begin
exec GTW1_CGT...grpc_Z001 @new_order output
end
else
if @arg_run_cv = 'S'
begin
exec GTW1_CGS...grpc_Z001 @new_order output
end
else
if @arg_run_cv = 'P'
begin
exec GTW1_CGP...grpc_Z001 @new_order output
end
else
return -900
EXAMPLE OF RESULTS (declare @new_order char(10) exec p_ppw_z001_next_order
'T',@new_order)
CORRECT (w/ Gateway)
GEN_ORDER
---------
0011257115 <<<<<< Row
@new_order
----------
0011257115 <<<<<< Argument
INCORRECT (w/o Gateway)
GEN_ORDER
---------
0011253908 <<<<<< Row
-
0 <<<<<< Argument
Thanks,
Tom
"Thomas Rundo" <tru...@a-asoftwaresolutions.com> wrote in message
news:45d0ced8@forums-1-dub...
Mark K
(gatewayless) as that would try to use site handlers, which are not
understood by the mainframe OSC.
As I understand it, if you have gatewayless with "cis rpc handling" = 1, you
get only the row, and not the arguments. You may want to trap the CICS
transaction with CEDX and step through it to see if there are any errors.
You may also have some other tool available, like Expediter, that would be
even better. It's been a long time since I've been on the mainframe side, so
I'm a bit rusty.
Although in looking at your proc code, it appears the @new_order is not
passed (it's an output var), in which case I would expect the "argument" to
not be set - if "argument" is what I'm assuming it is. Again, I think a
check of the mainframe code is probably best to see what is happening.
Mark Kusma
"Thomas Rundo" <tru...@a-asoftwaresolutions.com> wrote in message
news:45d0ced8@forums-1-dub...