Re: [7.3, ODBC] Problem with deleting SQL created libraries

I suggest a small (well, really not so small) problem with putting a reply
list entry in for an unsaved journal receiver.
On a development/QA/Hobby system, OK, I get it, take the risk.

On a production system, that is the very definition of a BIG LANDMINE for
recovery if journals are part of the recovery process. Even if you don't
think they are part of the recovery process, IBM i will use them if
available. If you have HA software (any one of them) that uses journals
it's highly likely that the software will recognise a new collection and
add it to it's configuration (maybe not if you have instructed the software
not to), then a problem happens and kaboom, real problems arise.

Better to just save the collection (proper name for an SQL created library)
and the data dictionary that is created with journaling just before trying
to drop it. That eliminates the need for the reply list entry. (remember
to update history with the save)

Another thing, (maybe not applicable in Patrik's case) if/when you upgrade
your OS, without proper documentation and a CLP that will redo all the
changes you made to IBM i objects, invariably you will forget you took
these steps and post upgrade blues will occur.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Thu, Mar 6, 2025 at 10:22 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello,

thanks to a friendly off-list answer, solutions have been established as
follows…


Am 06.03.2025 um 14:47 schrieb Patrik Schindler <poc@xxxxxxxxxx>:

First, there is a shared lock being held on the library from a spawned

qzdasoinit. The ODBC client seems stuck. Qzdasoinit stays for prolonged
time even if the remote side has closed the connection due to being
impatient.

chgsysval sysval(qliblcklvl) value('0')

Second, creation of libraries via SQL automatically creates objects for

journaling. If there was no save in the meantime, the OS posts messages if
it's okay to delete any unsaved receiver. This isn't visible for ODBC
clients, and again, the client seems stuck.

Allow the deletion of unsaved receivers to be answered with the default
answer. See wrkmsgd msgid(cpa7025).

Create a duplicate of the existing job description for qzdasoinit, and
change the duplicate to use the default reply entry of a message, instead
of requesting an answer

crtdupobj obj(qdftsvr) fromlib(qgpl) objtype(*jobd) newobj(qzdasoinit)
chgjobd qzdasoinit inqmsgrpy(*dft)

End the SBS running qzdasoinit, and change the prestart job entry to use
the new job description.

endsbs sbs(qusrwrk) option(*immed)
chgpje sbsd(qusrwrk) pgm(qsys/qzdasoinit) jobd(qgpl/qzdasoinit)
strsbs sbs(qusrwrk)

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.