Try IPLing the system in manual state and remove it using console. It would work. ===================================================== If DLTLICPGM fails (or failed) in a way that cannot be recovered, then it's possible that it ran far enough to delete the parts that feed the DLTLICPGM process. Manual deletion is your only choice. Use DSPSFWRSC to determine the library associated with product. Review objects in the library to determine any user profiles or authorization lists that might be part of the LPP but created in QSYS. E.g., an owner profile or product admin or other profile might have been created at install time. Then DLTLIB to delete the library. That should get rid of nearly all objects. Use DSPUSRPRF to see if other objects might have been created in other libraries during product use that are owned by the product user. Then DLTUSRPRF specifying that owned objects should be deleted or changed to another profile if you need to save them. (E.g., files might contain your data.) Then delete any authorization lists. Errors that occur during deletion (such that some objects might resist being deleted) will require manual review to determine what relationships need to be severed. Track down and fix these one at a time. When all appears clear, attempt the DLTUSRPRF or DLTAUTL again. Note that a directory structure might also be associated. You should be able to determine which subdirectories can be deleted. Use the 'recursive delete' function of EDTF over a directory to delete complete subdirectory paths. The *PRDDFN and *PRDLOD objects in the product library can sometimes be tricky. <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/sw1.htm">Software Product APIs</a> are available to delete these if necessary. The two APIs are almost trivial to call even from a command line. (Use x'0000000000000000' for the error-code parameter.) Tom

Try IPLing the system in manual state and remove it using console. It would work. ===================================================== If DLTLICPGM fails (or failed) in a way that cannot be recovered, then it's possible that it ran far enough to delete the parts that feed the DLTLICPGM process. Manual deletion is your only choice. Use DSPSFWRSC to determine the library associated with product. Review objects in the library to determine any user profiles or authorization lists that might be part of the LPP but created in QSYS. E.g., an owner profile or product admin or other profile might have been created at install time. Then DLTLIB to delete the library. That should get rid of nearly all objects. Use DSPUSRPRF to see if other objects might have been created in other libraries during product use that are owned by the product user. Then DLTUSRPRF specifying that owned objects should be deleted or changed to another profile if you need to save them. (E.g., files might contain your data.) Then delete any authorization lists. Errors that occur during deletion (such that some objects might resist being deleted) will require manual review to determine what relationships need to be severed. Track down and fix these one at a time. When all appears clear, attempt the DLTUSRPRF or DLTAUTL again. Note that a directory structure might also be associated. You should be able to determine which subdirectories can be deleted. Use the 'recursive delete' function of EDTF over a directory to delete complete subdirectory paths. The *PRDDFN and *PRDLOD objects in the product library can sometimes be tricky. <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/sw1.htm">Software Product APIs</a> are available to delete these if necessary. The two APIs are almost trivial to call even from a command line. (Use x'0000000000000000' for the error-code parameter.) Tom