Sure, I do it all the time...
I can't remember any issues to be concerned with at your level of code

I'm even running my aix adsm server with larger than 2GB db, log, and
storage files ;-)

OK, one thing... the "fsize" in /etc/security/limits has to be increased for
any user wishing to allocate a file over 2 GB
I think the base default fsize is only about 1 GB
Make sure root has either a -1 or a fsize greater than or equal to the fsize
of any user... this way when/if root is restoring a client's file he (root)
will be able to allocate the file big enough for adsm to put the data back
into it.

and for those who on an aix server are going to switch to over 2 GB files...
also remember to do this 'cause if you run dsmfmt and specify over 2GB the
error you get (or used to get) doesn't jump right out and say your fsize
isn't big enough... (gives something wierd that really isn't the case...
this is how I remember its an fsize problem :-O )

later ,
          Dwight



> ----------
> From:         Don Matush[SMTP:don.matush AT HIGHMARK DOT COM]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Tuesday, February 22, 2000 3:14 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      aix file size >2GB
>
> ADSM Backup Client  - Version 3, Release 1, Level 0.6
> MVS ASDM Server Version 3, Release 1, Level 2.50
>
> AIX has a feature on Journaled filesystems that allows the creation of
> files
> that are greater than 2GB in size.  Once the filesystem is defined as
> Large File
> enabled, the ulimit can be set above 2GB to allow larger file sizes.
>
> 1.  Can ADSM backup and restore files that are larger than 2GB?
>
> 2.  If, so, are there any issues with ADSM that one should consider when
> moving
> to a Large File enabled filesystem?
>
> Thanks,
>
> "This e-mail and any attachments to it are confidential and are intended
> solely
> for use of the individual or entity to whom they are addressed.  If you
> have
> received this e-mail in error, please notify the sender.  The views
> expressed in
> this e-mail message do not necessarily represent the views of Highmark
> Inc., its
> subsidiaries, or affiliate