SQL TOKEN -904 : Easy fix for a deleted LDS

-904 ( Resource Unavailable - LDS is not found in ISPF 3.4 ) error code is pretty much common in development/test environments as the retention period ( CATALOG ) for unused application LDS is set to a low value ( 100 days for example ). So, If you don't use an application table for more than 100 days for your development/tests the linear dataset ( VCATNAME.TEST.DSNDBD.TESTDB00.TESTTS00.I001.A001 ) is automatically deleted ( you can approach your storage/media management team to find out how ). You might have an image copy presence on tape and SYSCOPY catalog table for the table - But until you get back your LDS, it will not serve any purpose. I am about to share an easy way of creating the LDS for fixing -904 for the above scenario i.e - if the LDS is deleted :

Submit a DUMMY LOAD REPLACE job on the table, this will create the LDS. Example step of an DUMMY LOAD REPLACE  :

//STEP1        EXEC DSNUPROC,UID='TEST.LOAD',UTPROC='',SYSTEM='TEST'   
//STEPLIB    DD DSN=ACCOUNT123.DB2.R.TEST.DSNLOAD,DISP=SHR      
//SYSREC   DD DUMMY   
//SYSUT1      DD DSN=HILVLQ.TABLE00.SYSUT1,                            
//                    DISP=(MOD,DELETE,DELETE),SPACE=(CYL,(100,50),RLSE)  
//SORTOUT   DD DSN=HILVLQ.TABLE00.SORTOUT,                           
//                    DISP=(MOD,DELETE,DELETE),SPACE=(CYL,(100,50),RLSE)  
//SYSIN        DD *
LOAD DATA REPLACE LOG NO NOCOPYPEND INTO TABLE APPLN1.TABLE00

Once the LDS is created, use the RECOVER utility to bring back your data using the image copy.

Note & Precaution : Production LDS datasets are retained permanently in most of the accounts as a business need, until and unless the application is decommissioned and the cleanup activity is initiated.  -904 is also caused due to other factors and the resolution may vary. Performing a dummy load replace on an existing cataloged LDS will cause complete data loss and can impact your application drastically.