I agree with not using a maintenance id, MAINT, or even the canned SFS
servers. But this depends a little upon how varied the site is from vanilla
VM. But you sound like you want to get your feet wet also, so a little
playing around is called for.
Your original question does not tell what the tools are for or where they
come from, but I'm supposing that they are local, not IBM or other vendor.
Even if they are, I wouldn't put files available to production users into a
directory owned by MAINT (I wouldn't put the production S-disk on a minidisk
owned by MAINT either ;-). You can then separate what gets upgraded when
system changes occur. Makes for a better test environment too.
So, I would create a global filepool called 'MYCOMPNY' in a server id called
VMSFS001, and create a filespace within that called 'PUB', and create a
directory under that '.TOOLS'. Then I would 'GRANT AUTH MYCOMPANY:PUB.TOOLS
TO PUBLIC (READ NEWREAD', and finally modify SYSPROF to 'ACCESS
MYCOMPNY:PUB.TOOLS X'. I might be inclined to change the access filemode to
something right before the S-disk, maybe O, or P. BTW, there is no need for
the PUB filespace to exist as a user. In fact, I would avoid it.
So, while I would create another VM, it would be to host a new SFS filepool
for production. It would be global, though your site might not care. This
should safely get your feet wet. That is, you can play with the SFS server
to your hearts content, until you put it in SYSPROF. By then, you should
have all your backup and recovery capabilities in place. You should
probably create an SFS server called VMSFS002 for a filepool TSCOMPNY for
testing.
You get to pick better names.
Others have posted about DIRCONTROL and XC and an exit in SYSPROF, all good
points, so you can see there are issues to read up on before you put that
ACCESS in SYSPROF. Another issue is where to put the startup of VMSFS001;
early in the IPL process!
Last, and maybe most important, be sure you know how you are doing your
backups and recovery. There are different (vendor) solutions, and a
thorough understanding is important because SFS is different than minidisks.
Maybe practic recovering from VMSFS002 to VMSFS003 (named RECOMPNY).
----- Original Message -----
From: "Gentry, Stephen" <[EMAIL PROTECTED]>
To: <IBMVM@LISTSERV.UARK.EDU>
Sent: Friday, February 22, 2008 11:15 AM
Subject: Re: X Disk in SFS
You've got some catchin' up to do. 8-)
I would not use MAINT as a file space. Reason being, when new releases
of VM come out, you'll have to worry about backing your stuff up and
reloading it.
Taken literally, no need to set up another Virtual Machine (I take this
to mean install VM again and run it 2nd level or perhaps in an LPAR)
either. You can define another VM user, and define SFS space to it.
Then grant access to that space, those users who need it.
I've glossed over the details and can provide them if you like.
Steve G.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Fox Blue
Sent: Friday, February 22, 2008 11:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: X Disk in SFS
Dear all,
I am currently busy to understand the capabilities of SFS. Started in
the
late 80ies as system programmer we had VM/SP but there was no SFS. Since
one
year I am working on a z/VM installation and have to catch up with all
th
e
new facilities in VM.
I am wondering what would be best approach to define an X Disk in the
SFS
. I
mean, normally one puts the files accessible to all users on a mini disk
that everybody can access.
How can you do that with SFS? Should it be a directory in the file
space
of
MAINT or should I define an extra Virtual Machine for that? What would
be
the most common way of achieving this?
Thanks very much in advance.
Fox
