I was able to identify the documents in the OSM_OBJ_DIR that I would want to change the expiration for. One issue though, in your UPDATE statement you're updating the ODEXPDT but in my OAM table ODEXPDT is set to '0001-01-01'. What does look like an expiration date is ODPENDDT which is set to '2024-02-05'. Would that be the date to change?
I wouldn't recommend changing the ODEXPDT. As a general rule, we should avoid changing any derived attributes that the system could override and undo and worse of, cause data loss. Instead, change management class as if you were storing the object new, right now. Whatever the desired storage/management classes are, change to these classes. Next, you need to tell OSMC to adjust all other object transition dates (migration/expiration) by updating the ODPENDT to today or some old day.
If your management classes dictate a multi-tier storage (DASD, then TAPE (or tapeless-tape etc)) , ODPENDT would indicate the date of next transition to be applied by OSMC. By setting it to today after updating management class, you would be quite safe in protecting the data integrity within OAM.
In the past, I have migrated large OAM systems from one sysplex to onother remote sysplex on an external network, directly OAM-to-OAM on same sysplex due to LPAR consolidations where we had to combine OAM instances and migrate data from one OAM/LPAR into the other... some crazy stuff... So, this is what I strongly suggest to do, don't update the ODEXPDT because it is a derived field. Let OSMC calculate that for you based on ODPENDT and management classes.