Re: pcml program call error

[Dave Murvin <davem@xxxxxxxx>]

Gary,

I have run the PSHPINF in debug on a green screen and the parms look 
okay to me.  I will try to debug it when it is called from Java when I 
figure hour how to set the UPDPROD(*YES) in the WDSC remote debugger.   
Also, the PSHPINF program does not appear to blow up.  It looks like the 
problem is somewhere in the pcml after the PSHPINF program sets on LR.

Some additional info on this situation is that the pcml call works 
correctly when the Carriers are UPS and BAX.  The problem always happens 
with FedEx.  The difference is that for FedEx, the shipping package has 
to call out to a Windows FedEx server.  We were wondering if this 
Windows server call could be killing our connection.  We are trying to 
check on this.

Thanks

Dave


Gary L Peskin wrote:
> It does look like maybe the AS/400 program PSHPINF maybe blew up and didn't
> return an entire message.  Shown below are the parameters that you're
> passing.  Is this what you mean to be passing:
>
> DELIVERYNO Len: 11 Value: 00000151822
> PACKAGENO  Len: 10 Value:     736852  (there are four leading blanks)
> TOTALPKGS  Len: 11 Value: 00000000001
> USERID     Len: 15 Value: MICKYB           (there are nine trailing blanks)
> TRACKINGNO Len: 50 Value: TSTXas400.access.ConnectionDropped  (there are 16
> trailing blanks)
> STATUSCODE Len:  1 Value:  (the value is a single blank)
>
> The call to PSHPINF is supposed to return a stream of bytes that is at least
> 20 bytes long but it doesn't look like it received anything because, if it
> had, that would have been traced and it isn't.
>
> I would suggest that you run PSHPINF in debug again and see what it does
> with these parameters.  I suspect that it will blow up.  If so, the
> TRACKINGNO parameter looks a little funny to be.  Perhaps you could see how
> it's being populated.  Is the value supposed to be "TSTX" or what?
>
>