I read your other post and this post. I am looking to create the "SQL
Catalog VIEW objects" in the libraries. Sorry, don't have the terminology
down yet. I am confused why you say in so many words these Catalog View
objects are not needed.
Here is what I am trying to achieve. We have two libraries: TestLib and
ProdLib. I have SQL scripts to create SQL indexes over tables. The same
script is ran for both libraries. When I make changes to these
indexes/scripts and re-run them, I get the lovely index already exist error
message. A simple Drop at top of the script takes care of this, but wait
that causes problems on a new index (trying to create a standard template).
Solution, look up in the Catalog if the object already exists or not.
Well if I use the one in QSys2, the indexes are listed twice, once for each
library. Having the Catalog View objects in the libraries, I get what is
just in that library.
Am I missing something?
What is the point in wanting /the objects/ that make up a SCHEMA?
Regardless, the following script will effect the requested, for an
existing library named MYLIB:
crtjrnrcv mylib/qsqjrn0001 threshold(as_required_and_reasonable)
crtjrn mylib/qsqjrn mylib/qsqjrn0001 mngrcv(*system) dltrcv(*yes)
call qsys2/qsqxrlf (CRT MYLIB)
If the goal is actually automatic journaling, research QDFTJRN data
area. Note that the undocumented QSQXRLF API has almost surely still
not been updated to recognize that data area; i.e. the token QSQJRN as
name for a *JRN, is still required to exist to enable the API for an
invocation with token CRT as the first parameter, in order to effect the
creation of the SQL catalog VIEW objects in a user library.