Re: Backup of SQL tables and multi-member files

[Paul Therrien <paultherrien@xxxxxxxxxxxxxxxxxx>]

We are on V7R2 and when we execute a CPYF on an SQL table to create a 
new table we get an SQL table:

> CPYF FROMFILE(OMSMODF/MLEBLSFL) TOFILE(PJTLIB/TEST) MBROPT(*ADD) 
> CRTFILE( *YES)
  Physical file TEST created in library PJTLIB.
  Member MLEBLSFL added to file TEST in PJTLIB.
  37 records copied from member MLEBLSFL.

> CHGPF FILE(PJTLIB/TEST) MAXMBRS(*NOMAX)
  Maximum-member value not valid for file TEST.
  File TEST in PJTLIB not changed.

Can you show me how you executed your CPYF?


Paul
On 2018-03-01 13:38, Dan wrote:

> We're on v7r1.  I just tested CPYF of an SQL table to a new file.  I am
> able to change the new file via CHGPF MAXMBRS(*NOMAX).  I ran 
> additional
> CPYF commands to create new members.  The original SQL table and the 
> CPYF
> created file both have the same record format level ID.  (I did try to
> change the original SQL table to MAXMBRS(*NOMAX), but that failed with
> CPD3213.)
>
> Per the suggestion of adding a column to use to "filter" as a "member":
> YMMV, but that would be an absolute nightmare in our shop.  The work
> involved to refactor everything to get that to work, just for the sake 
> of
> creating a backup?  If you truly are limited to one member in a
> CPYF-created file, I think I'd come up with a scheme to your "backup"
> library that just backs up every file with a single member. The file 
> name
> would be Annnnnnnnn (through 999,999,999 iterations), Bnnnnnnnnn, etc.  
> The
> object description would be 'FILENAMExx LIBRARYxxx <timestamp of 
> backup>'.
> Maybe add a "master" file that identifies all of the backup files in 
> the
> library, including the attributes you feel are important to keep track 
> of.
>
> - Dan