Re: Size of Mdisk

[Rich Smrcina]

Oohh... niiice

Alan Altmark wrote:
I would be remiss if I didn't point out that CMS has a VSAM API redirector 
in it.  Look at the SUBSYS operand of FILEDEF.  We added it in 1984 or 
thereabouts and the SQL/DS product had hook to let it process VSAM 
requests.  I don't know if DB2 for VM/VSE still supports that.


Look at "Interface to an Alternate VSAM Emulator" in the CMS Application 
Development Guide for Assembler.  Your routine gets control on OPEN, 
CLOSE, and CLOSE TYPE=T with the address of the ACB.  On OPEN your routine 
fills in the read/write vectors in the ACB.


Alan Altmark
z/VM Development
IBM Endicott



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

Re: Size of Mdisk

[Alan Altmark]

On Friday, 09/07/2007 at 11:58 EDT, "Huegel, Thomas" <[EMAIL PROTECTED]> 
wrote:
> You write the requirement and I'll vote for it! 

"AVAILABLE" (via NFS).

> I wonder how difficult writing a VSAM to SFS block store driver would 
> be... hmm. Another project to do *later*.. 

I would be remiss if I didn't point out that CMS has a VSAM API redirector 
in it.  Look at the SUBSYS operand of FILEDEF.  We added it in 1984 or 
thereabouts and the SQL/DS product had hook to let it process VSAM 
requests.  I don't know if DB2 for VM/VSE still supports that.

Look at "Interface to an Alternate VSAM Emulator" in the CMS Application 
Development Guide for Assembler.  Your routine gets control on OPEN, 
CLOSE, and CLOSE TYPE=T with the address of the ACB.  On OPEN your routine 
fills in the read/write vectors in the ACB.

Alan Altmark
z/VM Development
IBM Endicott

Re: Size of Mdisk

[David Boyes]

Was thinking more of a CMS VSAM interface, but you're right that the
hooks might already be there. 

Re: Size of Mdisk

[Rich Smrcina]

At least for ESDS files, the VSAM hooks are already there (I don't know 
if KSDS would be any different or would really matter).  The TCP/IP 
Tools Transparent FTP support is built that way.


When a VSAM ESDS file is opened an FTP open is triggered, the data flows 
to or from the program through the FTP channels.  The process is 
controlled via JCL and a VSE librarian member handles the destination 
and FTP credentials.


David Boyes wrote:

I wonder how difficult writing a VSAM to SFS block store driver would
be... hmm. Another project to do *later*...



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

Re: Size of Mdisk

[Huegel, Thomas]

You write the requirement and I'll vote for it!

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of David Boyes
Sent: Friday, September 07, 2007 10:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Size of Mdisk


> Your last point.. Wouldn't it be so cool if VSE (zOS too) understood
SFS.. Especially now
> that VSAM is no longer available for z/VM.

That *is* a cool idea. I can submit it as a WAVV requirement; the VSE
lab is a lot more cooperative about that sort of thing, and the WAVV
guys tend towards the VSE environment more than SHARE does. I doubt z/OS
would ever use it (although it would be a very elegant way to get FBA
and SCSI disk support into z/OS in short order...)

I wonder how difficult writing a VSAM to SFS block store driver would
be... hmm. Another project to do *later*...


__
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com

Re: Size of Mdisk

[Rich Smrcina]

The VSE development lab won't be of much help there.  As far as they're 
concerned they already have an NFS client as delivered by the 
Connectivity Systems TCP/IP Stack (which is delivered as a 
pre-installed, priced feature with every VSE shipment).


Unfortunately that doesn't solve the problem for the significant 
percentage of the customers that are using TCP/IP Tools from Barnard 
Software (an alternative TCP/IP stack for VSE), which does not provide 
an NFS client.  Perhaps the requirement should go to Jeff... :)


David Boyes wrote:

Your last point.. Wouldn't it be so cool if VSE (zOS too) understood

SFS.. Especially now

that VSAM is no longer available for z/VM.


That *is* a cool idea. I can submit it as a WAVV requirement; the VSE
lab is a lot more cooperative about that sort of thing, and the WAVV
guys tend towards the VSE environment more than SHARE does. I doubt z/OS
would ever use it (although it would be a very elegant way to get FBA
and SCSI disk support into z/OS in short order...)

I wonder how difficult writing a VSAM to SFS block store driver would
be... hmm. Another project to do *later*...



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

Re: Size of Mdisk

[David Boyes]

> Your last point.. Wouldn't it be so cool if VSE (zOS too) understood
SFS.. Especially now
> that VSAM is no longer available for z/VM.

That *is* a cool idea. I can submit it as a WAVV requirement; the VSE
lab is a lot more cooperative about that sort of thing, and the WAVV
guys tend towards the VSE environment more than SHARE does. I doubt z/OS
would ever use it (although it would be a very elegant way to get FBA
and SCSI disk support into z/OS in short order...)

I wonder how difficult writing a VSAM to SFS block store driver would
be... hmm. Another project to do *later*...

Re: Size of Mdisk

[Alan Altmark]

On Friday, 09/07/2007 at 09:14 EDT, "Huegel, Thomas" <[EMAIL PROTECTED]> 
wrote:
> Your last point.. Wouldn't it be so cool if VSE (zOS too) understood 
SFS.. 
> Especially now that VSAM is no longer available for z/VM.

The common transform is NFS. 

Alan Altmark
z/VM Development
IBM Endicott

Re: Size of Mdisk

[Rich Smrcina]

Or maybe better, the Byte File System.  That would provide a 
hierarchical storage mechanism for VSE.  Yeah, there's an NFS client for 
VSE, but that's tied to a specific vendor... :(


Huegel, Thomas wrote:
Your last point.. Wouldn't it be so cool if VSE (zOS too) understood 
SFS.. Especially now that VSAM is no longer available for z/VM.




--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

Re: Size of Mdisk

[Huegel, Thomas]

Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS..
Especially now that VSAM is no longer available for z/VM.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of David Boyes
Sent: Thursday, September 06, 2007 8:26 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Size of Mdisk


> This application now has 2 3390-9s.
> The SFS sounds like a reasonable option.

Some tips about SFS:

1) Be sure to do the math for the size of the control disks and catalog
disks before you start seriously loading stuff into SFS and
overallocate, overallocate, overallocate; better too big than too small.
It's not trivial to change them later.

2) Give SFS fullpack minidisks for data storage when/if you can. Again,
it's not trivial to reorganize a filepool once you create it, and
consolidating SFS pool minidisks usually involves a dump and reload
which is disruptive (and a genuine PITA if you don't have a SFS-enabled
backup tool for CMS data). 

3) You may be tempted to use the VMXXX: filepools that come with VM;
DON'T. Those pools can't be shared between VM systems, the SFS servers
are hardcoded not to permit it. Build a separate filepool for your user
data.

4) The SFS security model is genuinely *weird*. If you're seriously
going to use SFS, make sure your ESM understands SFS (not all do), and
strongly consider buying Safe Software's SafeSFS. Trying to manage SFS
security with the native SFS tools will drive you bonkers faster than
sharing an office with your CEO and all your bosses at once. 

5) Get a commercial backup tool that really understands SFS. The native
SFS backup tools are difficult to use and understand. These days, that's
either VM:Backup or the IBM Backup Manager. VM:Backup is a lot easier to
install and use, but the IBM tools is a lot cheaper. 

6) Be cautious about granting PUBLIC access. There are impacts on the
security management that you may not expect. Ditto ADMIN access; read
the docs carefully. 

7) Find a copy of IPGATE (a nifty widget that lets you pass APPC traffic
over IP). It's really useful for 2nd level systems and remote access to
SFS from other VM systems, and if you're using SFS, you should have it
in your toolbox. 

SFS is neat, but it's not easy to administer. It'd be cool if something
other than CMS could use it effectively, but that's probably not ever
going to happen. 

-- db


__
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com

Re: Size of Mdisk

[Suleiman Shahin]

This storage space is not for long term legal information, but for keeping 
reports that someone might come back and report needed or missing.  The reports 
stay there for around 1 month then get deleted.

Thanks. 


Suleiman Shahin



> Date: Thu, 6 Sep 2007 22:29:33 -0400
> From: [EMAIL PROTECTED]
> Subject: Re: Size of Mdisk
> To: IBMVM@LISTSERV.UARK.EDU
> 


_
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

Re: Size of Mdisk

[Jim Bohnsack]

Everyone, or almost everyone, does the same type of thing.  You might 
ask yourself how far back you need to have quick access to an old report 
or listing.  For things that are probably never going to be seen again, 
write them to tape after "x" months.  I let the OPERATOR and some other 
service machines go to a disk and about a month after the "year end" 
backup with tapes that have a longer retention period, the years worth 
of accumulated disk files get erased.  Ask yourself if you weren't 
running VSE under VM, and, instead were printing this output, how long 
would you keep these listings.  Some things have to have a longer 
retention period.  Payroll/personnel files for instance often need a 7 
year retention period.  A lot of other things only need a few weeks or 
months.


Jim

Suleiman Shahin wrote:

--_d9390b76-537c-4b7a-8b8c-3218e89ea0fb_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Thanks David and Rich.

This application now has 2 3390-9s.

The SFS sounds like a reasonable option.

Suleiman Shahin



  

Date: Thu, 6 Sep 2007 20:31:55 -0400
From: [EMAIL PROTECTED]
Subject: Re: Size of Mdisk
To: IBMVM@LISTSERV.UARK.EDU
=20


I wonder how large an m-disk I can allocate for this app without going
  

overboard.




_
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=3D7+wonders+world&mkt=3Den-US&form=3DQ=
BRE=

--_d9390b76-537c-4b7a-8b8c-3218e89ea0fb_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}



Thanks David and Rich.This application now has 2 3390-9s.Th=
e SFS sounds like a reasonable option.Suleiman Shahin

> Date: Thu, 6 Sep 2007 20:31:55 -0400> From: [EMAIL 
PROTECTED]
nomine.net> Subject: Re: Size of Mdisk> To: [EMAIL PROTECTED]
RK.EDU> > > I wonder how large an m-disk I can allocate fo=
r this app without going> overboard.Explore the =
seven wonders of the world http://search.msn.com/results.aspx?q=
=3D7+wonders+world&mkt=3Den-US&form=3DQBRE' target=3D'_new'>Learn more!=

=

--_d9390b76-537c-4b7a-8b8c-3218e89ea0fb_--

  



--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: Size of Mdisk

[Suleiman Shahin]

Hello David,

I will save your instructions and follow them carefully when considering using 
SFS.

Thank you very much for the time you spent writing this 'document'.
And if I decide to follow the SFS route, I will let you know.

Sincerely,

Suleiman Shahin



> Date: Thu, 6 Sep 2007 21:25:35 -0400
> From: [EMAIL PROTECTED]
> Subject: Re: Size of Mdisk
> To: IBMVM@LISTSERV.UARK.EDU
> 
> > This application now has 2 3390-9s.
> > The SFS sounds like a reasonable option.
> 
> Some tips about SFS:


_
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

Re: Size of Mdisk

[David Boyes]

> This application now has 2 3390-9s.
> The SFS sounds like a reasonable option.

Some tips about SFS:

1) Be sure to do the math for the size of the control disks and catalog
disks before you start seriously loading stuff into SFS and
overallocate, overallocate, overallocate; better too big than too small.
It's not trivial to change them later.

2) Give SFS fullpack minidisks for data storage when/if you can. Again,
it's not trivial to reorganize a filepool once you create it, and
consolidating SFS pool minidisks usually involves a dump and reload
which is disruptive (and a genuine PITA if you don't have a SFS-enabled
backup tool for CMS data). 

3) You may be tempted to use the VMXXX: filepools that come with VM;
DON'T. Those pools can't be shared between VM systems, the SFS servers
are hardcoded not to permit it. Build a separate filepool for your user
data.

4) The SFS security model is genuinely *weird*. If you're seriously
going to use SFS, make sure your ESM understands SFS (not all do), and
strongly consider buying Safe Software's SafeSFS. Trying to manage SFS
security with the native SFS tools will drive you bonkers faster than
sharing an office with your CEO and all your bosses at once. 

5) Get a commercial backup tool that really understands SFS. The native
SFS backup tools are difficult to use and understand. These days, that's
either VM:Backup or the IBM Backup Manager. VM:Backup is a lot easier to
install and use, but the IBM tools is a lot cheaper. 

6) Be cautious about granting PUBLIC access. There are impacts on the
security management that you may not expect. Ditto ADMIN access; read
the docs carefully. 

7) Find a copy of IPGATE (a nifty widget that lets you pass APPC traffic
over IP). It's really useful for 2nd level systems and remote access to
SFS from other VM systems, and if you're using SFS, you should have it
in your toolbox. 

SFS is neat, but it's not easy to administer. It'd be cool if something
other than CMS could use it effectively, but that's probably not ever
going to happen. 

-- db

Re: Size of Mdisk

[Suleiman Shahin]

Thanks David and Rich.

This application now has 2 3390-9s.

The SFS sounds like a reasonable option.

Suleiman Shahin



> Date: Thu, 6 Sep 2007 20:31:55 -0400
> From: [EMAIL PROTECTED]
> Subject: Re: Size of Mdisk
> To: IBMVM@LISTSERV.UARK.EDU
> 
> > I wonder how large an m-disk I can allocate for this app without going
> overboard.


_
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

Re: Size of Mdisk

[David Boyes]

> I wonder how large an m-disk I can allocate for this app without going
overboard.

The largest usable CMS minidisk you can define is 1 cylinder smaller
than the physical size of the volume where the minidisk resides (cyl 0
of the disk is used for the CP volume label). 

If you need more space than that, and this is a CMS-based application,
you can use SFS, which allows you to allocate space to a userid that may
be physically spread across a pool of minidisks managed by a SFS server.
You can give a SFS server as many disks as you want(*) and it will
manage distributing the data effectively.

See the SFS Planning and Admin Guide for details on how to size and set
up SFS. It's a queer animal; know what you're up to before you set out
that direction. Note that SFS also has large impacts on system
management and tooling requirements (backup, etc). 


-- db

(*) within reason. There is a limit, but it's large. 

Re: Size of Mdisk

[Rich Smrcina]

z/VM supports very large disk sizes.  With the shared file system, you 
can pool disk volumes together into even larger minidisks.


How much disk space do you think you'll need?

Suleiman Shahin wrote:

Greetings folks,

I know this is elementary, but I have to ask!

I have an application that sends lots of VSE/POWER listings to a CMS 
userid with a hot reader that "reads" these files and stores them 
packed. The older files get deleted and new files keep coming and so on.


I wonder how large an m-disk I can allocate for this app without going 
overboard.

All ideas are appreciated.

Suleiman Shahin

Connect to the next generation of MSN Messenger  Get it now! 



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

Size of Mdisk

[Suleiman Shahin]

Greetings folks,

I know this is elementary, but I have to ask!

I have an application that sends lots of VSE/POWER listings to a CMS userid 
with a hot reader that "reads" these files and stores them packed. The older 
files get deleted and new files keep coming and so on.

I wonder how large an m-disk I can allocate for this app without going 
overboard.
All ideas are appreciated.

Suleiman Shahin


_
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline