How to validate DBB toolkit, database connectivity and RACF, and zAppBuild properties

[mhardin18]

I am often asked to validate things with regards to DBB/zAppBuild. Many of these tasks I manually do, though I have a few scripts of my own that do some of it. I realize that part of this inquiry is in regards directly to DBB and the database; but it has direct impacts to zAppBuild. This may be for a new client implementing DBB or for an upgrade of DBB to 2.x. In both scenarios zAppBuild is also in question.

How can I automate this?
Let me use Jazz as a simple example. When you go through the web wizard for the setup of Jazz, it requires you to input the required information to connect the database. It then has a Test Connection button. This validates that you have the correct database credentials, jdbc drivers, and the requisite environment settings.

I often need to validate the following items:
General DBB:

• DBB db2z database has correct RACF permissions.
• DBB_HOME is defined in /etc/profile or otherwise
• DBB toolkit has the correct permissions. i.e. /usr/lpp/IBM/dbb/bin and such are as they need to be.
• DB2 JDBC drivers

More zAppBuild:

• datasets.properties file is legit. i.e. the datasets exist and the members within such as IGYCRCTL actually are there.
• DB2z connection information in build.properties

NIce to have:

• Validate the dataset creation properties such as cobol_srcOptions

Future ideas:

• Bind information can be verified
• zUnit considerations

I realize that every environment is different, and that is why I am asking for advice.

[dennis-behm]

Hi Matthew,

thanks for reaching out - I think there are several ideas for enhancements which flow into different areas.

While toolkit permissions and environment variables are part of the host configuration guide of DBB, it misses to call out that it ships a validation.groovy script in $DBB_HOME/bin that provide a start for validating the setup.

$DBB_HOME/bin/groovyz validation.groovy

Info about this DBB installation
--------------------------------
DBB Version: 2.0.1
Build Number: 256
Release Date: 22-Jun-2023 14:29:33

Test MVSExec of IEFBR14
-----------------------
RC: 0

Can you please open an idea at http://ideas.ibm.com so that the Dev team can plan this work?

The idea should about extending the validation script to check:

• metadatstore connection
• assigned DBB role (btw - there is this a util available in https://github.com/IBM/dbb/tree/main/Utilities/PermissionCheck)
• ISPFExec / TSOExec configuration
• printing of the permissions of the toolkit
  And also mention that it has to be documented in the Host configuration guide?

For zAppBuild, we should plan for a "validation" cli option that validates:

• dataset properties and the existence of the libraries
  I will open an issue for that.

Thanks for bringing this up. Great ideas

Dennis

[mhardin18]

Thank you for your response. I was unaware of the validation.groovy script and the the other dbb utility scripts. Or at least I wasn't aware of their application. This is all good information.

I will open the idea.

[mhardin18]

https://ideas.ibm.com/ideas/DBB-I-60

[dennis-behm]

@mhardin18 - I have created a first pass for this - see #471 . The validation of the language specific settings are harder to perform, because these property files contain different build properties.

[mhardin18]

I like what I see.

As for the language specific settings, I'm not sure I can wrap my head around exactly what I would like to see...
Some feedback from clients has been that the default dataset allocation properties are not ideal. But I am interested in the design of why zApp uses those defaults.

But validating that they can be created/allocated besides attempting a build would be nice. Perhaps this is already there and I'm just not aware.

As a side note, I'm often having to add storage classes to the allocation directives. This would be a nice to have as a default property somewhere. I've been kludging it in with custom properties. But this falls more into the realm of specific implementations and I can see why this would not be appropriate for a default scheme.