When I installed IPGATE for my new customer (without RACF), at first I found
this in the IPGATE of the remote system:
CPICOMM LOGDATA H1 V 87 Trunc=87 Size=2 Line=1 Col=1 Alt=0
+2+3+4+5+6+7+8+.
* * * Top of File * * *
All userids on all systems are the same, so my
IPGATE USERMAP is
* * * Top of File * * *
;origin_system origuser resource locuser
;23456789012345 12345678 12345678 12345678
;VLB1.MF.ADP.COM
10.1.40.14 ***
The RESOURCE files for for both IPGATEs should be different:
- on the system where your SFS lives, the RESOURCE file should NOT
include the SFS. If it does, and IPGATE starts before SFS, IPGATE will own
your SYSVSFSE resource.
- on the other system, yes, there IPGATE should tell CP
So on the system owning the SFS server, the file is only comments.
Again no change. I also verified that the server has class B authority.
And did you look at the consoles of both IPGATEs?
Other information: what does SFS think about your connection. Suppose you
user userid A
- make sure user A is logged off on both systems
At the system with SFS:
- use some other user and issue Q FILEPOOL CONNECT
-- user A should not be there
At
I did this from maint:
id
MAINTAT SYSPROG1 VIA *03/12/10 14:06:40 EST FRIDAY
Ready; T=0.01/0.01 14:06:40
q filepool connect
This proves that something is terribly wrong: IPGATE passes userid * to SFS,
and not PTULLY.
I don't have a VM system ready now,
I bet you have three *s in the USERMAP instead of two * and one =
IPGATE USERMAP H1 V 80 Trunc=80 Size=10 Line=1 Col=1
that was it.
I had an * not an = in the last column
Thank you for all your help
I'm still not sure. I was able shut my test system down, where the SFS
server exists, re-ipl without RACF in the CP LOAD module.
I could not do the same to the secondary node.
This did not change anything. I am still only able to see files and
directories which are granted access to public.
Bruce,
I'm still not sure either.
I did a test today, brought down the node where the SFS server resides,
re-ipled with a CPLOAD which had no RACF in it.
Brought up the sfs server and IPgate, attempted the same connection from
the second system, still no luck. Only files and directories
Hello all,
I have recently implemented IPGATE between 8 VM systems. The connections
are
working fine but only for SFS directories/files which are available to Pu
blic.
I have been told that a generic profile in VMBATCH has been defined with
a
PERMIT of IPGATE with CONTROL
racf setr generic
On Wednesday, 03/10/2010 at 10:58 EST, Philip Tully
tull...@optonline.net wrote:
On the local system, I can access a tools. directory(which is public
read),
then select a sub-directory such as vmftp (which is NOT public is not
allowed to access, but I am).
On the remote system, I am able
It didn't but I added it with no apparent change, this is the directory
entry from the multitasking book:
*
USER IPGATE express 32M 64M BG
INCLUDE IBMDFLT
defined with a
PERMIT of IPGATE with CONTROL
racf setr generic(vmbatch)
racf rdef vmbatch * uacc(none)
racf permit * class(vmbatch) id(ipgate) access(control)
On the local system, I can access a tools. directory(which is public read),
then select a sub-directory such as vmftp (which
According to the racf team here (I don't have access) we have configured
racf as you said. BTW: we do not have a userid calls tools only a files
pace.
Here is the RACF output
VLB2
ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH
VXMBR VMXEVENT
15 matches
Mail list logo
