Re: SQL views missing after Cumulative PTF's applied

On 26 Aug 2013 11:30, Tom E Stieger wrote:

Yeah, now I have to go find any of MY old code that may still be
using sysdummy1!

Huge difference between SQL _code_ referencing SYSDUMMY1 and a VIEW referencing that TABLE. Albeit given the poor [IMO defective] design of any post-IPL PTF processing to effect DROP SYSIBM.SYSDUMMY1 then there is still a possibility that any code running after the DROP and before the re-create completes, still could be impacted. While the overall design\implementation makes that unlikely, it is not impossible. AFaIK the amount of pending work in the job wherein that activity runs is unpredictable and could delay until long after the user portion of an IPL starts; if the system jobs have implemented a high-priority enqueued work path, then the potential is greatly reduced, but I just read an APAR with MCH5801 as a symptom, from which I infer there is still no such priority path for the enqueued SYSIBM PTF activity.

The SYSDUMMY1 should have been designed like the [effectively identical in purpose] database file QSQPTABL in QSYS2, such that the file would almost never be deleted except in an actual /upgrade install/ [or when the required attributes or its data are incorrect]. The code could easily check if the TABLE already exists and inferred by some verifications to be functional, and only DROP the file *if* there is something wrong with the object or its data. Why anyone would code the DROP as unconditional, is unfathomable to me.

Regardless, using a user file or the row values-clause would eliminate any dependence on that system database file. However the /implementation/ of a row values-clause could be a query cursor over the system-table QSQPTABL in QSYS2. If some bone-headed PTF activity against that QSQPTABL file were to mimic the daft effect exhibited against the SYSDUMMY1 TABLE, then the same potential impacts would exist, though with an even more negative consequence because even some row value-clause invocations could fail; i.e. those implemented using a cursor on the QSQPTABL.