Groovy Compilation and Execution for mainframe Devops

[Pavankumarmurali]

• Does Executing Compiled Groovy scripts as a part of Mainframe Devops using IBM DBB cause a CPU reduction in comparison to running as Interpreted Groocy . If yes what is the observed CPU reduction

[dennis-behm]

Compiled groovy will reduce the need to interpret all the scripts for each build, and save some time.

Remember, that DBB 2.0.2.x comes with the DBB Shared Daemon to provide a pool of pre-launched JVMs that remove the JVM startup time, that can be resource hungry.

What version of DBB are you currently on @Pavankumarmurali ? Why is that interesting ? There were some findings in the DBB toolkit during Dependency resolution, which too more CPU than necessary. PH51990 is DBB 2.0.1 that has optimised that area.

Here is the full list of fixes: https://www.ibm.com/support/pages/fix-list-ibm-dependency-based-build

[mhardin18]

The personal daemon is almost useless to the extent that sys ops don't understand it and how OMVS and USS work with regards to it. And developers aren't doing that many user builds to warrant trying to implement it in an environment.

I have yet to find a situation where the shared daemons is effective either. With regards to doing pipeline builds and such, while the shared daemon could be useful, the cost of getting it setup and maintained vs not having it all... not having it is easier for my clients that have no experience in uss. And the spin up time of a new jvm process is negligible to the hours of education.

[ijmitch]

@mhardin18 these comments on adoption are pushing some of my buttons!

... not having it is easier for my clients that have no experience in uss. And the spin up time of a new jvm process is negligible to the hours of education.

Just to expand on this a bit, I can imagine someone with years of TSO/ISPF experience finding that they now need to be working out where to put a Process Definition file, edit it (without mucking up the codepage - which is what exactly?) in addition to the more familiar RACF and started task chores could be a bit daunted. Making assumptions about confidence in USS shouldn't really be a thing in 2024, but I'm sure it is in reality.

Is that the sort of experience you're describing/thinking about?

[reachsenthilnathan]

Matthew, I'm just clarifying one thing. I understand your point about personal daemons, and I completely agree that they are not a solution for scalability.

But when you said shared daemons, which version did you use? I am asking as we revamped the shared daemon in DBB 2.0.2

https://www.ibm.com/docs/en/dbb/2.0?topic=daemons-using-shared-daemon

Now the shared daemon can be used for pipelines and user builds. And unlike personal daemon, this is just one daemon that runs for every developer. So now the "spin time of new jvm process" vs this one time setup has changed. I do agree that we can do better explanations with Shared Daemons and we are working on it. We will try to involve you at the right point to get feedback on that effort.

[mhardin18]

@ijmitch
That is one aspect of which I'm describing. In general, I have found my clients with very little knowledge of USS. So even simple concepts take a while for them to master. When you put it on system admins that have no experience with it, just getting DBB stood up, along with git and the ported rocket tools... update java... it has been a challenge every time for us. It comes back to often not having the right skills for the admins... and clients not equipping/training them. We provide a lot of training with regards to IDz and how to configure DBB and such, and even git... but there is a lack of USS knowledge that getting them up and running... and even further, maintaining, these new concepts... just the wrong people with the wrong skill sets trying to do it. That has been my experience way more often than not.

[mhardin18]

@reachsenthilnathan

Senthil, I have not tried to implement it at a client since you have introduced the revamp in 2.0.2. The one client I could have the opportunity of introducing it for at the moment, I'm struggling mightily with the issues I just described. We are still working on them being able to troubleshoot pipeline DBB builds a year an months into this.

[ijmitch]

@mhardin18 - I don't know if you're aware of the free Introducing z/OS UNIX System Services course (and badge)? It's pretty up to date (seems to be largely 2021-era material) and even includes an online live exercise facility to get hands-on.

Could be worth recommending to your clients.

[mhardin18]

I was not aware of this one. It should be added to the Resources page. But even then, I can't get some clients to try and learn/train themselves.

[ijmitch]

I know what you mean @mhardin18 - there is a horse and some water involved here and getting them together is hard!