that was it.
I had an * not an = in the last column
Thank you for all your help
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
>
!...+1+2+3+...
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
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 t
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.
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 it
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 ***
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 * * *
_SPECIFIC_ERRO
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 wit
On Thursday, 03/11/2010 at 02:54 EST, Philip Tully
wrote:
> 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 t
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.
I don't know what is wrong. I tried it here, creating a filespace
that doesn't have a userid in the directory, and I could access it via
IPGATE on a remote system. You aren't, by chance, using RACF to
control SFS? I presume you aren't since you mention PUBLIC
directories. Maybe looking at the R
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
Did you also enable GENCMD for VMBATCH? I also made VMBATCH GENLIST
so that it is cached in memory. That requires a refresh whenever you
change it. Here is my setup:
RAC SETROPTS CLASSACT(VMBATCH)
RAC SETROPTS GENCMD(VMBATCH)
RAC SETROPTS GENERIC(VMBATCH)
RAC SETROPTS GENLIST(VMBATCH)
RAC RDEFI
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
On Wednesday, 03/10/2010 at 10:58 EST, Philip Tully
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 to access tools.
16 matches
Mail list logo