Where to Find Table in Backup LIB on AS400?

matrix0511
matrix0511 used Ask the Experts™
on
I executed the following tasks below to copy a table from one LIB (CRPDTA) to a backup LIB (TBLBACKUP).

However, after running this I would now like to verify the records in the table in the backup LIB to make sure everything went ok. But it fails when I try to run the table count.


Here is the tasks I took to backup/copy the table:

Save data in files before generating tables, if there are table generation requests.
- Using OWPKGBLD menu on OSK3, run option 25.
- Enter the following information:
  From file  . . . . . . . . . . . > F551201Z        
    Library  . . . . . . . . . . .     CRPDTA
  To file  . . . . . . . . . . . .      F551201Z
    Library  . . . . . . . . . . .     TBLBACKUP
  From member  . . . . . . . . . .   *FIRST        
  To member or label . . . . . . .   *FIRST        
  Replace or add records . . . . .   *NONE        
  Create file  . . . . . . . . . .   *YES                
  Print format . . . . . . . . . .   *CHAR

It said the copy was successful.

But when I try to check the records by running a record count command I get this:

                              Enter SQL Statements      
                                                         
 Type SQL statement, press Enter.                        
        select count(*) from crpdta/f551201z            
      SELECT statement run complete.                    
    >                                                   
                                                         
         select count(*) from TBLBACKUP/f551201z        
      F551201Z in TBLBACKUP type *FILE not found.        
    >                                                   
                                                         
         select count(*) from tblbackup/f551201z        
      F551201Z in TBLBACKUP type *FILE not found.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Gary PattersonVP Technology / Senior Consultant
Commented:
Does the user profile that you are using to run the query have rights to the backup file?  

Lack of authority to the lib or object is one possible cause.  Check the joblog of the job where you ran the STRSQL command to see if any authrity errors were logged.

Looks like you used a menu option from your application to make the copy - sometimes applications run under adopted authority, so the copy command could have completed even if your profile normally didn't have rights to the target library.

Verify the object exists using the WRKOBJ command.

Use the CHKOBJ command to determine if you have access to use the file:

CHKOBJ TBLBACKUP/F551201z TYPE(*FILE) AUT(*USE)

You can also try to use the DSPOBJAUT command to display the permissions associated with this file.

If you think security is the issue, ask your security administrator to grant you access to the file, or get someone that has appropriate data authority to query the file for you.

Post back if it doesn't look like it is a security issue.

- Gary Patterson
Theo KouwenhovenApplication Consultant

Commented:
Try WRKOBJ *all/f551201z  
then you get a list of all ibraries where f551201z    is located, maybe you mistyped something

Author

Commented:
Thanks guys. I won't be able to connect back to this client system until later this week. I'll try your suggestions then.

Thanks!
- Using OWPKGBLD menu on OSK3, run option 25.

Unfortunately, since we have no idea what that does, we also have no idea what the result would be. The entry parameters that you show after that sure look like regular parms for the CPYF command, but we don't know what that command was used for.

And it might not even actually be a CPYF command. It's not a difficult task to create a similar command interface that runs a radically different command-processing program.

It's possible that option 25 created a temporary file named TBLBACKUP/F551201Z and then immediately saved it into a savefile and deleted the temporary file. The savefile might even be zipped up and stashed in a /root directory until it's recalled by running some other option.

Both previous comments go in good directions to try to track down problems.

One thing to try for authorization is simply running the DSPLIB TBLBACKUP command. There will be one of three general possible outcomes. First, it might come back with 'Not authorized to library TBLBACKUP.' Second, it might list the library but show '*NOT AUTHORIZED' for the file description. Third, it will list everything and F551201Z will either be included or not.

The interactive SQL requests will only return the basic "not found" message that you showed. They won't give an indication that it was an authority problem, not even in your joblog. SQL is written not to give any extra help to someone snooping around to see if objects exist. The common external database access opens things up for snooping, so messaging is deliberately limited.

But original system commands can sometimes be more helpful.

Tom

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial