Your disappointment in IPGATE's hangups should be proportional to how
often your AVS server hangs up. IPGATE hangs maybe 4 times a year. If it
were supported we could call it in and sit with someone on the phone to
debug it, but it is a freebie and 4 times a year isn't that hard on our
operations.
If someone offered an encryption capable IPGATE, I will have to look
through my emails to see if I have any references to it. I like the idea
of being able to encrypt all data leaving my system, even if I don't
have to.
/Tom Kern
O'Brien, Dennis L wrote:
>> The three SFS filepools that I share (2 on CP system, 1 on IFL system)
> are
>> all GLOBAL resources.
>
>> I do find that once in a while IPGATE gets "confused" and
> non-responsive and
>> I have to recycle the SVM on both sides of the link.
>
>> Tom Kern
>
> I have the same problem with AVS. Once in awhile, a link just stops,
> and has to be restarted. I was thinking of switching to IPGATE to avoid
> that problem, so I'm disappointed to hear that IPGATE is no better. I'm
> also concerned that there's no support for IPGATE, because it isn't an
> official part of VM. Buying support from SNA or another third party is
> probably not an option for us. Someone from IBM asked us a few years
> ago if making IPGATE official would solve our problems with AVS, and we
> said yes. Alan Altmark, if our name isn't on the requirement, would you
> please add it?
>
> In the meantime, the internal version of IPGATE would be an improvement
> over what we have. I have an IPGATE VMARC file that I uploaded to VM on
> 5 Nov 2007, but I don't recall where it came from. It includes a
> version of the fix that Kris Buelens posted to the list on 29 Jun 2006,
> although it seems that some code was added along with the code that
> moved:
>
>> IPGATE did not pass the alternate userid of CMS clients to the SFS
> server
>
>> (in most cases that is).
>
>> The fix is simple:
>> - take the IPGATE1Y (S)MTREXX file,
>> - move the 4 lines staring with "address 'CPICOMM' 'XCECSU ... "
>> to before "if word(partner_LU_name,1) <> '*USERID'"
>
>> Kris Buelens
>
> Mine has:
>
> address 'CPICOMM' 'XCECSU cm_convid security_user_ID ',
> 'security_user_ID_length rc'
> if cm_return_code.rc = 'CM_OK' then do /* */
> Secu_user = left(security_user_ID,security_user_ID_length)
> If Secu_user <> Work_user then /* User has Alternate userid */
> parse value Secu_User Work_user'('Secu_user')',
> with Work_User Disp_user
> end
> if word(partner_LU_name,1) <> '*USERID' then do
> /* remote access -----------------------------************************/
>
>
> Dave Jones offered a version of IPGATE to the list on 18 Jun 2007, that
> included encryption:
>
>> I've added an encryption capability to IPGATE so that the data flowing
>> across the TCP/IP network is shielded from nosy folks....drop me a note
>
>> off-list if you're interested. And many thanks to Perry and Holger for
>> helping me understanding the code well enough to add this feature in.
>
> I did send Dave a note, but I don't think what I have was from him.
> Searches for the strings "Jones" and "crypt" do not return any hits.
> Most of the files are dated 19 Mar 2006. The Mar 2006 files are either
> identical to the files in SG245164 VMARC (e.g. RES* EXEC, or aren't in
> SG245164 VMARC (e.g. SAMPMAIN MTREXX, TIME MTREXX, VMTIMED MTREXX).
> IPGATE1Y (S)MTREXX includes Kris' fix, and is dated 29 Jun 2006.
> IPGATE1 (S)MTREXX is dated 3 Jul 2006. The only note file in the
> package is MTREXX NOTES, which contains Perry Ruiter's original notes on
> MTREXX.
>
> The difference in IPGATE1 is one line:
>
> NEW 62 parse value socket('Bind',socketid,'AF_INET' listen_port
> 'INADDR_ANY') with rc .
>
> OLD 62 parse value socket('Bind',socketid,'AF_INET' listen_port
> tcp_host_id) with rc .
>
>
> Dennis
>
> "A pistol! Are you expecting trouble Sir?" "No Miss, were I expecting
> trouble I'd have a rifle."
>
