so we can now find DBM values inside the sysibmadm.DBMCFG table, the
DB values inside the sysibmadm.DBCFG table.

Where can I find the ADMIN CONFIG / DAS values inside the database?
Is there such a place?

Thanks,
Chris

<cbielins (AT) gmail (DOT) com> wrote

Admin server is deprecated (still there, but may be gone in a future
release). It is there to support the Control Center, which also is
deprecated.

On Mar 7, 1:27*pm, "Mark A" <no... (AT) nowhere (DOT) com> wrote:
so....are you saying this information should be available to us
through the database on 9.5 and lower? If so, would you know where?

<cbielins (AT) gmail (DOT) com> wrote

No, I believe that having the db and dbm cfg available in an admin table is
a recent enhancement (not sure which release it is first available), and IBM
may have felt like that since Admin Server is going away (even though it is
still around if you want it), then they won't make the admin cfg available
in an admin table. This is my speculation, since I don't work for IBM.

Hi Chris,

No, there is no administrative view to retrieve DAS values.

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On Mar 7, 3:18*pm, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:

Thanks Helmut.... I'll have to parse the "get admin cfg" then to
achieve the values that I'm looking for.

No biggie..

On 07.03.11 19:47 , cbielins (AT) gmail (DOT) com wrote:
What values are you actually looking for? The administration server is
deprecated and will be removed in the future.

I assume you are using the DAS for scheduling tasks. You should consider
switching to the new infrastructure.
You might want to check out the ADMIN_TASK_ADD procedure.
http://bit.ly/hVJbw7

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On Mar 7, 4:58*pm, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:

We are trying to become compliant with the Center of Internet Security
(CIS) benchmarks, CIS DB2 Benchmark v1.1.0 (thru v9.5). A part of
those benchmarks is gathering information on the DAS: DASADM_GROUP,
DISCOVER, EXEC_EXP_TASK, and SCHED_ENABLE. We were able to suffice
the other (DB/DBM) parms by using the sysibmadm tables, but fell short
trying to capture these values from within the database.

Chris

On 07.03.11 22:58 , cbielins (AT) gmail (DOT) com wrote:
Understood. Well, you could write a stored procedure in C, which returns the
parameters you need (that is, if you haveto retrieve the data via SQL).
Or, if you don't need the DAS, it might be more effective to delete it.
No DAS, no chance to fail compliance. :-)

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On Mar 7, 8:58*pm, "cbiel... (AT) gmail (DOT) com" <cbiel... (AT) gmail (DOT) com> wrote:

Not related to the question at hand, but my experience using these
security benchmarks (both the CIS benchmark and the DOD checklist, as
well as some vendor security scanning tools) is that these are often
written by people who don't know / use DB2. Therefore, they
frequently include recommendations that don't make sense, or there are
often holes in the recommendations.

For example, the CIS recommendation about AUDIT_BUF_SZ illustrate this
point exactly. It says:

Increasing the audit buffer size to greater than 0 will allocate
space for the audit records generated by the audit facility; and
will cause the audit records to write asynchronously, thus ensuring
no loss of audit records.

AUDIT_BUF_SZ is a performance parameter. Increasing it from 0 will
help eliminate performance issues caused by synchronous writes to the
audit logs. Any buffering offers the chance that audit records will
be lost -- which is exactly the opposite of what the document says.

Another example, I have seen these formulas that recommend restricting
access to SYSCAT.%AUTH views (which isn't a bad thing), but they don't
recommend anything about the underlying SYSIBM tables, so the security
hole is still open.


These security checklists are a good starting point, but they should
NOT be used as a simple checklist. Don't be afraid to ignore some
recommendations, too -- just understand what the risks are and do what
you can to mitigate against them.


Just make sure that you understand WHAT the document is trying to
accomplish, and then apply that to your database.



Ian Bjorhovde
DBA & Survivor of many DOD security audits