WEBVTT
00:00:08.000 --> 00:00:09.119
Hi everyone.
00:00:09.279 --> 00:00:15.519
Thanks for joining us for this series of iDug Podcasts, where we speak to some great people in the DB2 community.
00:00:15.679 --> 00:00:16.960
I'm Marcus Gavage.
00:00:17.120 --> 00:00:20.640
And I'm Julia Carter, and we represent the iDug Content Committee.
00:00:20.800 --> 00:00:22.879
We hope you enjoy today's edition.
00:00:32.560 --> 00:00:39.920
Joining us in the studio today, we have Juren Tissen, who's the Senior Technical Staff Member at Rocket Software.
00:00:40.159 --> 00:00:40.719
Welcome.
00:00:41.119 --> 00:00:41.600
Welcome.
00:00:41.920 --> 00:00:43.759
Yeah, thank you for having me.
00:00:44.240 --> 00:00:49.840
I'm a longtime listener of your of your podcast, so it's uh nice to be here.
00:00:50.159 --> 00:00:51.359
Laura, great to have you.
00:00:51.439 --> 00:00:54.560
And are you our first Rocket person?
00:00:55.280 --> 00:00:56.000
I think you might be.
00:00:57.520 --> 00:01:00.799
Yeah, that's probably well, you had uh Anthony a while ago.
00:01:00.880 --> 00:01:03.439
He he had a brief stint at Rocket Software.
00:01:03.759 --> 00:01:04.879
That's true, yeah.
00:01:04.959 --> 00:01:05.280
Yeah.
00:01:05.439 --> 00:01:08.079
But current employee, I think you're our our first.
00:01:08.319 --> 00:01:08.959
Yeah, thank you.
00:01:09.280 --> 00:01:15.519
Laura, it's good to have you here, and we're excited to hear about your life with and without DB2.
00:01:16.000 --> 00:01:17.040
So where should we start?
00:01:17.519 --> 00:01:19.920
Right at the beginning, how did you get into DBT?
00:01:20.799 --> 00:01:23.439
Well, yeah, that's kind of an interesting story.
00:01:23.599 --> 00:01:27.920
Um I I do have like a different background than than most people.
00:01:28.079 --> 00:01:32.799
Um I have actually I have a PhD in uh relativistic quantum chemistry.
00:01:33.120 --> 00:01:38.400
Yeah, I had to Google that because I read it and I thought I have no idea what it is about.
00:01:38.799 --> 00:01:39.760
Okay, what is that?
00:01:40.079 --> 00:01:55.200
Uh well well, quantum mechanics is quantum mechanics, but then sort of the chemistry part of it is really applying it to um chemistry or chemical uh problems, and then the relativistic part is really applying the the um the special relativistic theory to that.
00:01:55.519 --> 00:02:02.480
So um right now when we are recording, there's been a lot of discussion about gold and silver, like last week, if you follow that.
00:02:02.879 --> 00:02:11.520
And if if you know the periodic system with chemistry, that you know that gold and silver or silver is uh you know they're in the same column of the periodic system.
00:02:11.680 --> 00:02:15.599
So you would expect them to have similar properties, chemical properties, and so on.
00:02:15.759 --> 00:02:20.080
But you wouldn't you know that silver is silver colored and gold is gold-colored.
00:02:20.319 --> 00:02:29.840
And the reason why they are a different coloring is because of the relativistic uh you know effects on on the atom because the electrons are moving close to the speed of light.
00:02:30.000 --> 00:02:34.639
Uh so that's kind of the very short explanation of that.
00:02:34.800 --> 00:02:34.960
Uh.
00:02:36.080 --> 00:02:40.639
And didn't you do didn't you do a degree in chemistry as well?
00:02:41.039 --> 00:02:46.159
Yeah, so I I well I have a master's degree in chemistry first and then the PhD subsequently.
00:02:46.319 --> 00:02:50.479
Um, chemistry was your passion.
00:02:51.280 --> 00:03:01.680
Um it started out being chemistry, but then when I had like experimental chemistry in the lab, uh I would normally ruin for like thousands of pounds of equipment every time.
00:03:01.919 --> 00:03:07.680
And my lab coat was like full of uh holes from when I spilled you know assets and whatnot.
00:03:08.080 --> 00:03:17.520
So at some point, I I don't know if it's if it was me or somebody else sort of pointed me towards a theoretical chemistry rather than the experimental chemistry.
00:03:19.360 --> 00:03:22.479
You sound like a stereotypical mad professor then.
00:03:23.039 --> 00:03:24.159
Uh yes, yeah.
00:03:24.400 --> 00:03:29.199
My lab coat was like green and blue and red, and and yeah, that was not not good.
00:03:29.280 --> 00:03:29.759
Yeah.
00:03:30.000 --> 00:03:41.120
So it is chemistry, but I kind of found that uh theoretical chemistry is like one-third math, one-third computer science, and then one-third physics, so it was very little chemistry.
00:03:41.280 --> 00:03:52.319
Uh and most of my time I spent coding uh Fortran 77 uh programs, sort of implementing the the physical formulas in in Fortran 77.
00:03:52.719 --> 00:03:53.199
Oh wow.
00:03:54.000 --> 00:04:00.560
Running on you know, cray um machines and silicon graphics and IBM AIX and so forth.
00:04:00.800 --> 00:04:05.520
So that was how I got into sort of the IT uh IT part of it.
00:04:05.759 --> 00:04:18.800
Then while I was uh studying at university, I started playing backgammon and uh I joined the open source backgammon project, um, GNU Backgammon um that were writing an open source backgammon uh program.
00:04:18.959 --> 00:04:23.199
This was written in C, so that was how I sort of became proficient in C.
00:04:23.920 --> 00:04:29.600
As a side note, uh GNU backgammon was based, the engine was based on neural networks.
00:04:29.759 --> 00:04:31.519
So this was very early days.
00:04:31.680 --> 00:04:41.680
The the the brain of GNU Beggammon had a an N well today LLM type thing with I think like 10,000 parameters.
00:04:41.920 --> 00:04:47.120
No, today's LLMs or neural net, they have like 100 billion or one trillion parameters.
00:04:47.199 --> 00:04:49.279
So it was it was in the very early days.
00:04:49.439 --> 00:04:53.439
Uh so I worked with neural nets before it became cool.
00:04:54.399 --> 00:04:54.879
Well done.
00:04:55.839 --> 00:04:59.120
Some would argue that it's always been cool, but yeah, yeah, yeah.
00:04:59.759 --> 00:05:03.680
So you got your PhD in relativistic quantum chemistry.
00:05:04.000 --> 00:05:04.319
Yeah.
00:05:04.720 --> 00:05:05.439
Say what?
00:05:05.920 --> 00:05:11.839
Well, so so I'd done a lot of the coding in C, uh both at university and then uh in that open source project.
00:05:11.920 --> 00:05:14.480
And then IBM was looking for C programmers.
00:05:14.720 --> 00:05:21.519
They did mention some weird platform in the uh job advert, but I did a platform I knew nothing about.
00:05:21.680 --> 00:05:24.480
But I knew C, so you know how hard can it be?
00:05:25.360 --> 00:05:28.079
And that weird platform was uh MVM.
00:05:28.319 --> 00:05:30.079
Yeah, it was IBM mainframe.
00:05:30.160 --> 00:05:33.439
Uh so I I knew nothing about the mainframe then.
00:05:33.600 --> 00:05:45.439
Um but I started in IBM as uh like a junior developer or trainee or whatever you call it back in in 2001, writing C programs on this weird platform to make it even weirder.
00:05:45.519 --> 00:05:48.480
Sort of the transaction manager was IMS GM.
00:05:48.720 --> 00:05:51.920
Uh but the the database was was db2.
00:05:52.160 --> 00:05:56.399
Um but don't tend anyone that I know anything about IMS.
00:05:57.519 --> 00:05:59.680
Don't worry, your secret safe with us.
00:06:01.199 --> 00:06:07.120
So so that was kind of how I uh started on on mainframe, really as an application developer.
00:06:07.439 --> 00:06:17.360
This was like IBM's internal IT, we were creating uh internal applications, but yeah, they were running on mainframe, IMS, TM, and DB2 as the database engine.
00:06:18.079 --> 00:06:22.959
Then over time it within that application, I became the application DBA.
00:06:23.040 --> 00:06:30.560
So that was kind of how I made it into sort of more the the DBA or or more DB2 side uh of things.
00:06:30.879 --> 00:06:42.959
Then fast forward a number of years, I think it was late 2009, uh, my manager said that they were looking for a DB2 expert in the in the in the IBM sales organization, like a pre-sales specialist.
00:06:43.279 --> 00:06:51.839
And so I I moved over uh yeah, probably late 2009 or early 2010 and and became a pre-sales specialist.
00:06:52.079 --> 00:06:59.120
So kind of a switch because I had I had the application background rather than sort of a system system DBA background.
00:06:59.279 --> 00:07:02.240
So I did have to learn a lot of things.
00:07:02.560 --> 00:07:25.600
Luckily, I got one of those uh CPDTs, like the mainframe emulators, and I that was uh I I I can hear right now that there's some discussion about IBM removing it, but uh for me back then it was really a good source of of education because you had your own system, and if you screw something up, you would just sort of start from scratch and and try again.
00:07:25.839 --> 00:07:30.399
So that's that's kind of how I learned initially sort of this the system side of things.
00:07:30.639 --> 00:07:38.879
So I I think I ended up knowing too much about SMS and REGF and all kinds of other things mainframe related from from that CBDT.
00:07:39.040 --> 00:07:45.920
Uh because you when you run the CBDT for half an hour, then you know SMF runs full or Jess runs full or whatever.
00:07:46.000 --> 00:07:50.000
So you kind of had to learn a lot of uh systems programming to to keep it running.
00:07:50.319 --> 00:07:52.079
That's when you become dangerous.
00:07:52.480 --> 00:07:53.120
Yeah.
00:07:53.519 --> 00:07:53.920
Yeah.
00:07:54.160 --> 00:07:56.720
Yeah, I I know enough to be dangerous.
00:07:58.160 --> 00:08:02.399
And that that's also kind of how I came into the idoc world.
00:08:02.560 --> 00:08:08.160
So I was working as a pre-sale specialist, and a lot of my customers went to the idoc conferences in Europe.
00:08:08.240 --> 00:08:13.920
And so I I started going a well, probably 2010 was probably the first one.
00:08:14.000 --> 00:08:23.920
And I I can have no idea where it was, but I attended all the iDocs probably since then, maybe missed a single one in Europe at least.
00:08:24.160 --> 00:08:36.320
Um so initially I I I I went as a participant, and for me it was like a learning experience uh because I I was new sort of in the system side of DB2 and the engine side.
00:08:36.480 --> 00:08:42.080
So I went to all the the presentations with the iBemers back then and learned a lot about the engine.
00:08:42.639 --> 00:08:58.639
Um I I don't hope Bart Stigman's this listing, but I remember probably one of the first years I had like a whole afternoon on SMF data or you know, IFC IDs in DB2, and that was probably a bit over my head at at that time, so I think I almost fell asleep.
00:09:02.799 --> 00:09:05.279
A few hours of that, yeah, I can I can understand.
00:09:05.600 --> 00:09:06.159
Yeah.
00:09:06.399 --> 00:09:11.039
Um, but uh it was really good education for me uh back then.
00:09:12.000 --> 00:09:22.720
Going back to my open source sort of um uh contributions, that was kind of uh where I started with sort of um you know community contribution or what you would call it.
00:09:22.799 --> 00:09:28.639
Uh we had a mailing list and I would participate, and that's how I ended up sort of coding on the project as well.
00:09:28.879 --> 00:09:41.519
Back then, at some point, I I joined the IDoc list um and sort of at some point I can't remember exactly when started contributing and answering questions or participating in the um in the discussions, etc.
00:09:41.759 --> 00:09:48.559
So obviously, I I think that that's also good education, sort of to participate in in the discussions.
00:09:48.720 --> 00:09:49.600
You learn something, you know.
00:09:49.679 --> 00:09:52.000
If you write something, it's wrong, somebody will correct you.
00:09:52.960 --> 00:09:57.519
As long as it's constructive, then I think that's that's very good as well.
00:09:58.240 --> 00:10:07.919
Yeah, and it's it's good that you bring that up because whenever I search for something and it's the the DB2L as it used to be, your name is always there in the conversation.
00:10:08.000 --> 00:10:09.519
So you're always contributing.
00:10:09.600 --> 00:10:17.200
And it must take quite a lot of time to be constantly checking and and adding to that, but your contributions are really valuable.
00:10:17.600 --> 00:10:18.639
Yeah, thank you for that.
00:10:18.879 --> 00:10:31.039
Um well, yes, it is time, but I I I still see a lot of it as education because if if somebody is asking that question on the IDOC list, you know, I might get the same question from a customer at some point.
00:10:31.120 --> 00:10:34.559
And so it's in a lot of cases it is valuable.
00:10:34.879 --> 00:10:38.080
Or it might be something that a customer already asked me, so I already know the answer.
00:10:38.159 --> 00:10:40.000
So it's just a matter of writing it.
00:10:40.559 --> 00:10:41.440
Sharing it, yeah.
00:10:41.679 --> 00:10:42.240
Yeah, yeah.
00:10:42.480 --> 00:10:52.559
So but I I think in general it's it's very valuable to participate in communities like that, um, you know, for yourself but also for the the ones that wrote the question.
00:10:52.720 --> 00:10:55.679
Um so yeah, and you speak now.
00:10:55.759 --> 00:11:16.240
I mean, you say you started in 2010 and you were there to learn, but now you speak in every conference all around the world, and your sessions are always really well attended, and I think you get a lot of engagement, and I think people take a lot from your sessions because of the way, the unique way that you can explain things so that everybody gets it.
00:11:16.559 --> 00:11:17.679
Yeah, thank you for that.
00:11:17.919 --> 00:11:26.320
Uh yeah, so as I mentioned, I started participating in iDoc, and then at some point I can't remember when I started submitting presentations.
00:11:26.480 --> 00:11:30.879
I I always kind of had an interest in sort of new stuff that's come along.
00:11:31.039 --> 00:11:34.720
So that's has frequently been the topic of my presentations.
00:11:34.879 --> 00:11:42.720
Or it's somebody that's a customer, something that a customer asked about, and I had to do a lot of research and then I kind of make that into a presentation.
00:11:42.960 --> 00:11:49.759
So I I presented on sort of newer things like your Python, pipelines, Ansible, and and so on and so on.
00:11:49.840 --> 00:11:56.399
Um so that's you know, from a personal point of view, it's it's always nice to learn something new, sort of keep you fresh.
00:11:56.480 --> 00:12:05.120
Uh so I like to spend some time on on learning new topics that that come along in in the in the db2 area or sort of around it.
00:12:06.399 --> 00:12:11.840
And with Python, I actually learned Python back at at university as well, many, many years ago.
00:12:12.000 --> 00:12:14.240
Python is quite an old language as well.
00:12:15.759 --> 00:12:18.399
But it's it's it's becoming more and more popular.
00:12:18.799 --> 00:12:21.919
You were doing it at university, so that was a few years ago.
00:12:22.000 --> 00:12:23.519
Um late nineties, yeah.
00:12:23.679 --> 00:12:26.480
So yeah, I didn't realize it would be around that long.
00:12:26.960 --> 00:12:30.159
Python was written in around 1990, something like that.
00:12:30.320 --> 00:12:32.080
Uh the early 90s.
00:12:32.399 --> 00:12:32.960
Yeah.
00:12:33.279 --> 00:12:33.679
Yeah.
00:12:33.840 --> 00:12:43.200
So because I had an interest in IT, I I actually took some parts of the sort of the computer science curriculum at university, even though I was a chemist.
00:12:43.519 --> 00:12:53.200
Um, and and we a lot of the um they were using Python for a lot of the courses there, uh, like algorithm theory and so on.
00:12:53.360 --> 00:13:02.000
Uh I I did one on assembler programming and and I did one where we use C, so I kind of that's where I learned some of those programming languages.
00:13:02.159 --> 00:13:12.320
Um then Python was kind of dormant for me for many years, and then it kind of because it sort of became useful in the mainframe world, it's kind of where I picked up the interest again.
00:13:12.480 --> 00:13:15.279
So I have like a 15-year gap, Python gap.
00:13:17.120 --> 00:13:20.879
But luckily, yeah.
00:13:21.200 --> 00:13:23.919
Um yeah, it's it's becoming more popular now.
00:13:24.080 --> 00:13:30.000
Um uh you know, with younger people that do not necessarily want to or have to learn REX.
00:13:30.799 --> 00:13:34.720
Now for some things Python is a is a nice replacement.
00:13:34.960 --> 00:13:36.399
Um I I like it a lot.
00:13:36.639 --> 00:13:47.679
It's very it's very flexible, and there's a lot of libraries of modules you can you can pick and you know you know, passing JSON or YAML is like one line of code.
00:13:47.759 --> 00:13:50.320
I I would hate to write that in REST.
00:13:50.720 --> 00:13:52.559
Yeah, I wouldn't like to do that in REX.
00:13:53.759 --> 00:14:07.679
I'd like to take this opportunity to thank you personally for helping me with Python and trying to get it working, talking to DB2 using the uh IBM DB2 libraries on the mainframe and talking to the mainframe.
00:14:07.919 --> 00:14:11.360
Because I've just recently been mucking around with Python.
00:14:11.600 --> 00:14:14.480
And it's uh yeah, you've been very very helpful.
00:14:14.559 --> 00:14:15.200
So thank you for that.
00:14:15.679 --> 00:14:17.440
Everything's up and running and working now.
00:14:17.840 --> 00:14:23.519
Yeah, it it's a bit complicated and and it's somewhat different from running it on, let's say, your laptop.
00:14:23.759 --> 00:14:28.080
Yeah, just like yesterday that was I had a question from another customer.
00:14:28.399 --> 00:14:34.559
Came internally that somebody had asked one of our about one of our products and Python and IBMDB.
00:14:34.639 --> 00:14:38.240
So there's there's a lot of interest in that uh and and Python in general.
00:14:38.480 --> 00:14:44.240
Maybe I should sort of dust off my original Python and IBMDB presentation and and resubmit.
00:14:44.399 --> 00:14:55.039
Uh I think it was recorded for iDoc North America and it's out there on YouTube and it's I would say 90% still valid, but there's a few things and a few improvements since then.
00:14:55.200 --> 00:14:57.679
So yeah, sounds good.
00:14:58.399 --> 00:15:01.600
Yeah, that on the agenda for Porto, maybe.
00:15:01.919 --> 00:15:02.559
Yeah, yeah.
00:15:02.960 --> 00:15:04.720
Maybe I maybe I'll do that.
00:15:05.279 --> 00:15:24.080
Do you think that the the modernization piece that we're all faced with at the moment is one of the bigger challenges of your customers at the moment in the fact that there are people that want to do it that are almost pushing for it, but there is quite maybe resistance to to actually go with it.
00:15:24.480 --> 00:15:26.559
Yeah, I think that's exactly right.
00:15:27.919 --> 00:15:35.120
I I think a lot of customers struggle just to keep the lights on on their shop and they don't really have time to look at other things.
00:15:35.360 --> 00:15:46.960
But uh on the other hand, if you want to attract um new uh younger people to the platform, I I think we need to have some alternatives to to ISPF and and batch.
00:15:47.519 --> 00:15:52.240
So I I don't see ISPF going away anytime soon.
00:15:53.519 --> 00:16:03.360
Not in not in my lifetime, maybe, but uh I I do see like a a shift and an interest uh towards more modern interfaces.
00:16:03.679 --> 00:16:20.240
But of course, uh a lot of the products that we we all work on in the db2 tool space, they have no 20, 30 years of legacy and it's 1,000 functions, and it's really, really hard to make every single function and all of the options available in a modern UI.
00:16:20.320 --> 00:16:26.320
So that's yeah, but that is a challenge that's going to be a challenge for the future.
00:16:26.799 --> 00:16:35.120
And Zoe, as part of the open mainframe project, is making uh a good dent in that respect.
00:16:35.519 --> 00:16:42.320
Yeah, yeah, Zoe and there are many other things uh that are trying to you know add those modern interfaces.
00:16:42.480 --> 00:16:47.519
So yeah, at some point you know we we need to have everything available in a different way.
00:16:47.600 --> 00:17:02.399
And it can be web UIs for some features, or the features is more API that you can consume from, say, a Python program, or you can write your own sort of integrations, might be CLIs, you know, all kinds of interfaces that allow you to perform things.
00:17:02.639 --> 00:17:08.079
You can all you're all starting to see you know Python libraries for some features.
00:17:08.240 --> 00:17:20.880
IBMDB is obviously one thing, but now there's also SDSF available as a Python library, so you kind of get more and more functionality available, you know, some modern way, you know, API libraries or whatever.
00:17:20.960 --> 00:17:21.039
Yeah.
00:17:21.200 --> 00:17:23.920
So you can you can build your own integration.
00:17:24.240 --> 00:17:26.160
Uh I think it's also good.
00:17:26.400 --> 00:17:35.920
Maybe in the past, customers would either be, you know, BMC or Broadcom or IBM, but with APIs, you can kind of mix and match and get the best of everything.
00:17:36.160 --> 00:17:46.160
Even though we might prefer to have one specific stack, uh, I think it's still it's valuable for customers to be able to mix and match and even have like open source components at as part of that.
00:17:46.559 --> 00:17:47.680
Yeah, that's a really good point.
00:17:47.839 --> 00:17:57.680
It does add that flexibility, doesn't it, potentially to to pick and choose the best or the most applicable bits to what you're trying to achieve or the problems you're trying to resolve.
00:17:58.079 --> 00:17:58.400
Yeah.
00:17:58.640 --> 00:18:11.519
I have seen uh threads on community forums where people have been saying, yeah, but you can't write ISPF panels in in Python, but you can in REX.
00:18:12.640 --> 00:18:19.359
Well, then the question is if you need ISPF panels, you can easily create text-based UIs in Python.
00:18:19.680 --> 00:18:22.720
Then you would run it in in uh in ZOS Unix instead.
00:18:22.960 --> 00:18:27.039
But yes, it would not be ISPF, uh, it would be a different text UI.
00:18:27.680 --> 00:18:30.079
But it it may or may not be possible.
00:18:30.319 --> 00:18:37.279
Maybe customers or some users prefer web UIs and others they prefer more more CLI-based uh operations.
00:18:38.000 --> 00:18:44.160
So I I don't know if I I buy that that there's no ISPF in Python.
00:18:44.240 --> 00:18:45.920
I I don't I don't think it's necessary.
00:18:46.160 --> 00:18:46.480
Yeah.
00:18:46.880 --> 00:18:54.319
It's the change of mindset though that hey, I have this nice ISPF panel, and now I want to have the same, but with Python at the back, and well, no, sorry.
00:18:54.480 --> 00:18:58.160
You'd either have to write a web UI or text uh UI.
00:18:58.720 --> 00:19:00.240
I I have great success.
00:19:00.400 --> 00:19:02.960
Uh you call it wipe coding.
00:19:03.119 --> 00:19:04.960
Uh use Copilot for Python.
00:19:05.039 --> 00:19:06.400
It's it's very good at Python.
00:19:06.480 --> 00:19:12.160
Uh and I I just say, hey, give me a web UI, this and this and this, and it'll write the code for me.
00:19:12.480 --> 00:19:22.880
So you can you can you can quickly create uh you know not production level code, but at least some prototypes to see how it how it might look like and and work.
00:19:23.839 --> 00:19:35.440
So as a as a former developer that had like a 15-year gap in my development, I did not do much development, then having tools like that to help me is is very, very useful, I find.
00:19:35.680 --> 00:19:36.000
Yeah.
00:19:36.240 --> 00:19:44.880
I don't know, maybe I'm 90% vibe coding, so I just ask Copilot and then I'm making small modifications to the to the resulting code.
00:19:45.440 --> 00:19:48.559
I've played around with um vibe coding.
00:19:48.799 --> 00:19:55.519
Uh can't stand the term because it goes against decades of uh software engineering training.
00:19:55.759 --> 00:20:04.960
Uh but just uh to just to talk to something which has got full access to uh everyone's libraries and everybody's bad code.
00:20:05.359 --> 00:20:09.759
Uh I have had good experience with it, and it is it is good fun.
00:20:09.920 --> 00:20:14.240
And I've churned out some really good Python programs which access db2.
00:20:14.960 --> 00:20:15.920
Yeah, exactly.
00:20:16.000 --> 00:20:28.720
Um I I had a customer request come in, and they they from one of the tools we do for IBM, they wanted to have some an a new report or a new layout of an existing report, and and they wanted to save it in a db2 table.
00:20:28.799 --> 00:20:36.319
And I I I created a prompt in Copilot and it spit out 200 lines of Python code, and I had to make two modifications.
00:20:36.480 --> 00:20:50.480
Um the the DDL was embedded and it had like a syntax error in the DDL, and then going back to the IBM DB module, it was using like a distributed connection string to DB2, and I wanted to run it on ZOS Unix, so I had to change the connection string.
00:20:50.640 --> 00:20:58.400
But the program ran and it passed the report, put it into a DB2 table, and it was like five minutes of of work for me.
00:20:58.799 --> 00:20:59.119
Yeah.
00:20:59.759 --> 00:21:06.400
Uh so I I see it, it's very powerful for sort of prototyping or one-offs of these kind of things.
00:21:06.799 --> 00:21:09.599
Yeah, I guess you need the attitude though, don't you?
00:21:09.759 --> 00:21:12.640
It's not like this can do my job for me.
00:21:12.960 --> 00:21:13.279
No.
00:21:14.319 --> 00:21:25.920
It's just got to be like the basis or to help generate the ideas and the initial stepping stones, and then you've got to use your your actual human elements to bring it all together.
00:21:26.240 --> 00:21:27.119
Right, yeah.
00:21:27.279 --> 00:21:29.279
I use it a lot for prototyping.
00:21:29.359 --> 00:21:35.519
Uh, so when we're looking at sort of innovation items and we want to see how this actually looks like or would it work, etc.
00:21:35.759 --> 00:21:42.079
It's you can use it sort of to quickly build a prototype, and then somebody in development will have to create something that actually works.
00:21:42.319 --> 00:21:43.359
I think that's yeah.
00:21:45.440 --> 00:21:47.279
And and test it and so on.
00:21:47.599 --> 00:21:48.480
Oh, yeah, testing.
00:21:48.880 --> 00:21:49.920
Do people still do that?
00:21:52.160 --> 00:21:53.599
Check in production, test it.
00:21:54.400 --> 00:21:56.160
Doc documentation and so forth.
00:21:56.240 --> 00:21:56.559
Yeah.
00:21:58.000 --> 00:21:58.640
Yeah.
00:21:59.039 --> 00:22:03.200
So we uh We left you in technical sales, in pre-sales in IBM.
00:22:03.920 --> 00:22:05.359
So then what happened?
00:22:05.519 --> 00:22:08.319
How did you get into Rocket and what do you do now?
00:22:08.880 --> 00:22:17.599
Um yeah, so so then uh I was there six or seven years uh and then in 2007 I I applied for a job at Rocket.
00:22:18.240 --> 00:22:26.240
Sort of just before that, uh Rocket was taking over the development, a lot a lot of the um the IBM brand, the DB2 tools.
00:22:26.480 --> 00:22:38.160
I ca I really like sort of the interaction with development, not necessarily being a developer myself, but sort of the interaction, sort of advocating on behalf of the customer, being close to development.
00:22:38.400 --> 00:22:56.000
And so I kind of wanted to be closer to development, so I I applied for a job in I don't know, late 2016, and I joined Rocket in in 2017, still kind of as a pre-sales um specialist, and then that's kind of what I am still today, although my title has has changed since then.
00:22:56.240 --> 00:23:19.119
So we help IBM at the back end with uh with pre-sales activities, post-sales, deployments, and and obviously being close to development, we we help with uh innovation and some of the new features and um being like the the customer advocate um to make sure that what we actually develop is something that the customers want and uh it's what they need.
00:23:20.160 --> 00:23:39.359
Um you know in in these days with with sort of more agile development and and uh the continuous delivery, obviously now there's there's much shorter feedback cycle compared to you know years back where you would have a new release of a product every three years, and and there will it will be much slower feedback cycle than than today.
00:23:39.519 --> 00:23:51.279
So there's a lot of interaction with customers um on new features and and what you know if we're doing the right thing and so on, including that modernization we talked about um earlier.
00:23:51.519 --> 00:23:54.960
So yeah, so that's that's what I've been doing since then.
00:23:55.039 --> 00:24:02.240
So I ended up being 16 years, I think, in in IBM and now I've been eight, nine years in in Rocket.
00:24:02.640 --> 00:24:07.279
I think I'll have 25 years of mainframe anniversary this year, I guess.
00:24:07.519 --> 00:24:07.839
Yeah.
00:24:11.039 --> 00:24:11.680
Yeah, thank you.
00:24:11.920 --> 00:24:13.519
Doesn't make you feel old, does it?
00:24:14.880 --> 00:24:18.000
Um well, yeah, I guess.
00:24:18.079 --> 00:24:28.240
I don't know if it's a positive or negative thing, but in in Denmark, uh you know, they raise the retirement age with sort of the based on your uh uh expected lifespan.
00:24:28.319 --> 00:24:31.519
So I can I can retire in at 71, I think, maybe.
00:24:31.920 --> 00:24:32.720
71.
00:24:32.880 --> 00:24:33.759
Oh my goodness.
00:24:34.319 --> 00:24:36.799
And they might put it up before you get there.
00:24:38.079 --> 00:24:39.920
So I have 20 years to go.
00:24:42.079 --> 00:24:48.720
So you've worked with gosh, you said 25 years working with the mainframe.
00:24:48.799 --> 00:25:00.960
So what do you think have been, in your opinion, the uh the big developments, the the wows of db2 and the mainframe in in those 25 years?
00:25:01.920 --> 00:25:11.920
I I think it's very difficult when you when you've been in the world, you kind of see sort of the small increments, and it's you you have really have to think about what was the major developments.
00:25:12.079 --> 00:25:22.400
Uh I as I mentioned, I like to look at new features, so that's kind of always where my focus is on sort of the the past new features.
00:25:22.640 --> 00:25:28.160
I I don't know with the actual mainframe, I think there's some major developments, it's kind of all incremental to me.
00:25:28.400 --> 00:25:32.240
But if if I look at some of the recent features, um I really like.
00:25:32.480 --> 00:25:41.519
And because I've never been a production DBA, I've I've only been an application DBA, I I never really had the responsible responsibility for a production system.
00:25:41.680 --> 00:25:45.440
I did break it as an application developer, that's a different story.
00:25:48.319 --> 00:25:58.240
Um but I sort of sort of some of the recent features I find really interesting is is the redirected uh recovery um uh feature of DB2.
00:25:58.559 --> 00:26:07.680
Uh in the past it was really impossible for customers to actually test uh recoveries now, unless they had like a DR environment where they could run these kind of things.
00:26:07.759 --> 00:26:17.680
Uh but now with the redirected recovery, you can run a recover test uh in your production environment and see, you know, demonstrate that you can actually recover.
00:26:17.759 --> 00:26:28.319
You are recoverable, figure out how long time it takes, um, and then sort of extrapolate to you know what is my um my RTO for an entire system.
00:26:28.400 --> 00:26:38.319
Um and we've seen quite many customers uh doing redirected recoveries uh and learning all kinds of interesting lessons about recovery.
00:26:38.480 --> 00:26:40.799
So I think that's I think it's a good thing.
00:26:40.960 --> 00:26:44.400
You know, we've seen customers that find out that that tape is slow.
00:26:44.480 --> 00:26:49.839
You know, if you have archive, it takes a long time to recover.
00:26:50.079 --> 00:26:55.920
Um and so the the um disk storage seller was happy after that.
00:26:57.119 --> 00:26:58.640
Yeah, of course.
00:26:59.839 --> 00:27:08.000
Um and I also think our customers found out that the R2 might be slower than they you know promised in some of their uh documents.
00:27:08.559 --> 00:27:09.440
Or they were told.
00:27:09.519 --> 00:27:14.079
I think often it's just they were told what the RTO would be, and it's like we can recover in four hours.
00:27:14.160 --> 00:27:15.279
Yeah, yeah, sure.
00:27:17.039 --> 00:27:18.240
We have no idea.
00:27:18.559 --> 00:27:19.519
Yeah, yeah, yeah.
00:27:19.759 --> 00:27:20.960
Now they have an idea.
00:27:21.759 --> 00:27:28.799
And also I uh some customers have learned sort of important operational experience with recovery because they have never done them before.
00:27:29.119 --> 00:27:31.039
You know, how do you restart a recover job?
00:27:31.119 --> 00:27:32.640
You know, what do you do when something breaks?
00:27:32.799 --> 00:27:34.000
What can break, etc.
00:27:34.400 --> 00:27:41.839
So I think for a lot of customers that has been a good way to learn without you know being in an actual recover situation.
00:27:42.400 --> 00:27:57.119
Yeah, I agree that redirected recovery is a big step forward, but for me personally, I feel like it needs to go further because some places aren't going to be happy about you running a recover job in a production environment unless it's actually an emergency and you need to do it.
00:27:57.279 --> 00:27:59.519
Because it's it there is a risk to it still.
00:27:59.680 --> 00:28:04.240
If you get one little thing wrong, it could be wrong.
00:28:04.559 --> 00:28:05.119
Very simple.
00:28:05.359 --> 00:28:12.640
Yeah, I I did have one customer that gets some got something wrong there, so that's one of the sort of the fall falls under the operational experience.
00:28:12.960 --> 00:28:13.599
Right.
00:28:14.000 --> 00:28:25.119
But I I I've I've seen some customers that are that are doing it quite well and they will set up RackF rules, etc., that prevents you from from sort of harming the production system.
00:28:25.200 --> 00:28:32.240
So there are there are some good ideas out there to make sure that you don't shoot yourself in the foot, uh, as I've seen some customers do.
00:28:32.480 --> 00:28:48.000
But I I do have some customers that have recovered 10, 20, 25% of production system over like a weekend to get really, really good estimate of of how how long time it will take to to recover their production environment in case it it uh you know they need to.
00:28:48.880 --> 00:28:51.759
So yeah, that I think that's an exercise, isn't it?
00:28:51.839 --> 00:28:58.000
I mean that's a really good undertaking because you'd have to put a load more DASD there for that.
00:28:58.160 --> 00:28:59.920
And well goodness, yeah.
00:29:00.160 --> 00:29:05.519
Just thinking about all the all the operational and practical things that you need to do in order to actually achieve that.
00:29:05.599 --> 00:29:06.960
That's that's quite a major exercise.
00:29:07.200 --> 00:29:07.759
Yeah, yeah.
00:29:08.079 --> 00:29:15.359
That particular customer, they had they had sort of capacity, at least CPU-wise, in in over the weekend, uh, so they had they they could run it there.
00:29:15.440 --> 00:29:18.400
But yes, they needed like 25% additional DASD.
00:29:19.440 --> 00:29:36.160
Um but that there's some good lessons to be learned uh of doing maybe you don't need to do 25%, maybe you can do five or ten percent, but there has to be some kind of non-trivial amount of data you recover to get, otherwise it'd be difficult sort of to extrapolate to to the full full amount of data.
00:29:36.240 --> 00:29:37.359
Uh sure, yeah.
00:29:37.519 --> 00:29:38.960
Yeah, but they're interesting.
00:29:39.680 --> 00:29:48.720
I I like I like that um feature a lot, and I I think uh those customers that have tried it out uh are also big fans of it.
00:29:49.039 --> 00:29:53.680
Um then another rather recent feature is the utility history.
00:29:53.839 --> 00:29:57.599
I know BMC has had that for for some years, but now it's in the IP.
00:29:59.200 --> 00:30:00.400
Nice to see you catch up.
00:30:00.480 --> 00:30:01.279
Well done.
00:30:02.559 --> 00:30:11.200
Yeah, I I think Hawkon Rupert has uh admitted that that has been an RFE or whatever it was called before RFEs for for quite many years.
00:30:11.279 --> 00:30:14.960
Uh but but it finally arrived in in DV2 version 13.
00:30:15.119 --> 00:30:18.960
And there's a lot of valuable data in that, you you you would know that.
00:30:19.119 --> 00:30:24.960
Uh but yeah, looking at you know uh CPU, elapsed time, etc.
00:30:25.759 --> 00:30:33.759
Have you seen customers actually using the data in uh in a positive way to provide insights into what they're doing with their utilities?
00:30:34.079 --> 00:30:39.920
Yes, and I think there have been some IDoc presentation, I believe, um, from some customers on that.
00:30:40.000 --> 00:30:42.000
Um I think from Commerce Bank.
00:30:42.559 --> 00:30:49.599
Uh I I I think I don't know if that's positive or negative, but I think some customers realized how much CPU copy is using.
00:30:49.839 --> 00:30:50.079
Oh.
00:30:50.880 --> 00:30:57.839
And so I think Hokon Robots commented on that, and they actually had to add SIP SIP uh enablement in the copy utility.
00:30:58.640 --> 00:30:59.839
Win win then.
00:31:00.160 --> 00:31:00.480
Yeah.
00:31:00.799 --> 00:31:04.720
Because now it was very visible how much CPU you were burning on image copies.
00:31:04.880 --> 00:31:05.519
Yeah.
00:31:05.839 --> 00:31:21.440
But I I think there's a lot of valuable, valuable data in the utility history uh in in terms of also if you're planning to run a utility, you know, how long time did it take last time, and you can maybe extrapolate or do more clever things with with the data.
00:31:21.680 --> 00:31:25.519
So I think that's I I think that's a very powerful feature.
00:31:25.759 --> 00:31:30.079
It is still quite new, and a lot of customers had only made it to version 13.
00:31:30.240 --> 00:31:33.119
And it is something you have to enable, obviously, through a CPAM.
00:31:33.359 --> 00:31:42.960
So but I you know we hope that once customers start collecting this data, um, we have a lot of plans sort of to to exploit that data for for various things.
00:31:43.119 --> 00:31:50.400
But uh and the nice thing is that it's you know it's collected by the customer themselves, so it's it's very environment-specific uh for them.
00:31:50.559 --> 00:31:53.680
So it's very useful data in these kind of contexts.
00:31:54.000 --> 00:31:54.640
Yeah.
00:31:56.319 --> 00:32:00.240
Then maybe that's an older feature, but the Dv2 system profiles.
00:32:00.400 --> 00:32:02.799
I I can't remember when they were came around.
00:32:03.039 --> 00:32:05.200
They are some versions old.
00:32:05.279 --> 00:32:06.640
I don't know if you can remember them.
00:32:07.599 --> 00:32:09.119
Mark's we're googling it.
00:32:09.279 --> 00:32:09.920
Yeah.
00:32:12.400 --> 00:32:13.680
Version 10?
00:32:14.240 --> 00:32:17.279
Yeah, I was thinking version 10, but it might be version 9.
00:32:17.519 --> 00:32:23.680
I I think it's a wildly underused feature uh and maybe underappreciated feature.
00:32:23.839 --> 00:32:40.079
Uh I I've gotten a lot of questions from customers that said, hey, we have this remote application connecting, and uh they had a loop and they consumed all our threads or connections, or they ran some ugly SQL, and I I have no idea who it is and where they came from, and how do I get rid of them?
00:32:40.240 --> 00:32:46.480
And you can do that with the system profiles, um, you know, penalty box or even blog applications.
00:32:46.720 --> 00:32:53.759
Um and I I I talked to several customers that basically uh penalty box every application they have.
00:32:54.079 --> 00:33:00.319
Oh, so anyone that connects, they okay, you can have five threads or ten connections, but not more than that.
00:33:00.559 --> 00:33:03.279
I I asked them, hey, hey, what if you show good behavior?
00:33:03.440 --> 00:33:05.039
Can you get out of the penalty box?
00:33:05.200 --> 00:33:05.920
Uh no.
00:33:08.160 --> 00:33:08.720
Strict.
00:33:09.039 --> 00:33:10.240
That's very strict.
00:33:10.559 --> 00:33:16.319
Yeah, but it it gives you a way sort of to proactively um protect your db2 subsystem.
00:33:16.480 --> 00:33:22.079
And I I think a lot of customers seeing the distributed workload increasing and increasing.
00:33:22.640 --> 00:33:28.000
And it's obviously the for some customers it's the wild, wild west, at least large customers.
00:33:28.160 --> 00:33:41.200
You know, they have thousands of developers, and and the DBAs have no idea who is connecting to the system, there's no control, and the system profiles give them that control and and the ability to proactively manage it.
00:33:41.519 --> 00:33:49.119
You can also set special registers, so you can set Apple Compad for applications that may not tolerate a high Apple Compad, or vice versa.
00:33:49.279 --> 00:33:55.920
Uh, if you have the uh IBM and analytics accelerator, you can you can set the special register related to that.
00:33:56.000 --> 00:34:08.079
And there's all kinds of uh interesting things you can do on the system side rather than asking you know a random developer you you have no idea who is uh to set the right parameters um at their end.
00:34:08.239 --> 00:34:12.239
So I think that's an underused feature uh and underappreciated.
00:34:12.639 --> 00:34:34.320
I I I really like that, especially when I hear some of those customer stories, both from those that have done it up front, so they kind of save the DV2 subsystem, but also when those customers I talked to that have not used it, then understand, hey, you know, I now I could actually I could uh put that user in a penalty box or even prevent them um from connecting.
00:34:34.480 --> 00:34:37.760
So um yeah, I think that's that's a very nice feature.
00:34:38.079 --> 00:34:39.280
Yeah, it's a really good point.
00:34:39.360 --> 00:34:42.239
And I don't think anyone's ever mentioned that one before when we've asked them.
00:34:42.559 --> 00:34:48.000
But I think you're right, it's underused and underappreciated perhaps and could be very powerful.
00:34:48.400 --> 00:34:49.039
Yeah.
00:34:49.840 --> 00:34:55.199
And sort of in that DB2 has added a lot of instrument instrumentation for distributed workload.
00:34:55.280 --> 00:35:01.440
Uh so you get more and more insight into what is actually connecting from what IP addresses and users and so forth.
00:35:01.599 --> 00:35:07.039
So now you kind of have you have the instrumentation and now you have the sort of the hammer.
00:35:10.000 --> 00:35:20.079
So you know, so you can kind of create some kind of monitoring and and then also uh implement uh the profiles um and and and manage your workload that way.
00:35:20.239 --> 00:35:26.639
I think that's that will become increasingly pop popular as more and more distributed workload are are coming in.
00:35:26.880 --> 00:35:32.800
It's probably there that the the highest uh sort of the the growth in workload is from distributed, I think.
00:35:33.199 --> 00:35:33.519
Yeah.
00:35:33.760 --> 00:35:42.719
So so the the last thing I thought about was the very recent feature, and so and the jury is still out whether that will be popular or not.
00:35:42.960 --> 00:35:46.239
Um that is uh open telemetry tracing.
00:35:46.639 --> 00:35:48.880
Uh right, that's quite new, isn't it?
00:35:49.199 --> 00:35:49.840
Yeah.
00:35:50.400 --> 00:36:04.559
So IBM recently shipped uh open telemetry tracing for all of the subsystems, so db2, IMS, uh KIX, Kix Transaction Gateway, uh MQ, ZOS Connect, maybe something I've forgotten.
00:36:04.800 --> 00:36:29.840
Um so it's really sort of the the sort of the holy grail of the end-to-end monitoring that everybody has has wanted for many many years, but it was very difficult to follow a transaction that originated like on a mobile phone and all the way through whatever systems, all the way down to db2, and then kind of understanding what happened and if something is wrong, who who is the culprit?
00:36:30.480 --> 00:36:33.760
Um so it it looks very promising.
00:36:34.159 --> 00:36:35.920
Uh it is a new feature.
00:36:36.079 --> 00:36:38.639
Uh customer adoption, I think, is still unclear.
00:36:38.800 --> 00:36:42.800
There are some customers that are interested in it, obviously, otherwise IBM would not do it.
00:36:43.039 --> 00:36:46.079
Um but it yeah, the jury is still out on that.
00:36:46.320 --> 00:36:59.679
I I did together with a colleague uh Christoph, we we wrote a blog on on like how do you instrument a Java program and all the way down to DB2, and you can s you can follow follow that trace and uh and see everything.
00:36:59.840 --> 00:37:04.559
And uh Christoph, my colleague, is going to submit that for for uh Porto this year.
00:37:04.639 --> 00:37:06.159
So oh that would be interesting.
00:37:06.239 --> 00:37:07.599
Yeah, it'd be good to see that.
00:37:08.000 --> 00:37:08.480
Yeah.
00:37:09.519 --> 00:37:11.760
So that's that's a very recent feature.
00:37:11.920 --> 00:37:16.400
Uh so we we will see you know how how that is uh received by by customers.
00:37:16.480 --> 00:37:18.079
Uh it is very interesting.
00:37:18.400 --> 00:37:19.039
Yeah.
00:37:19.280 --> 00:37:24.719
Um yeah, and obviously AI is is uh is interesting as well.
00:37:24.960 --> 00:37:32.880
Um IBM has shipped an an agent, DB2 agent that you can connect to to your LM.
00:37:33.119 --> 00:37:37.280
So that I've I I foresee there'll be a lot of lot of things going on in that space.
00:37:37.840 --> 00:37:41.360
It's a very hot topic across everything AI.
00:37:42.719 --> 00:37:44.000
Absolutely, yeah.
00:37:44.559 --> 00:37:50.639
So, how do you think AI will affect the role of the DBA and the sysprog going forward?
00:37:50.880 --> 00:37:55.519
What kind of changes, what kind of DBA would use AI tools?
00:37:56.159 --> 00:37:57.679
Yeah, that's a good question.
00:37:57.920 --> 00:38:02.639
Um so so personally I'm using AI a lot.
00:38:02.719 --> 00:38:07.360
Uh you know, I have Copilot home all the time, asking all kinds of questions.
00:38:07.599 --> 00:38:14.719
Um I I think like for for I mentioned Python, it's very good at write writing Python code.
00:38:14.880 --> 00:38:19.519
I I can also get some some OKJCL out for some some things.
00:38:19.679 --> 00:38:24.880
Uh but I I think mainframe is kind of um a niche area.
00:38:24.960 --> 00:38:26.320
So so I think so.
00:38:26.400 --> 00:38:32.320
I think those AI engines need to be, you know, you cannot use sort of the general ones to get good answers there.
00:38:32.400 --> 00:38:38.960
You need something on top of that, so like a mainframe-specific LLM that has some additional information.
00:38:39.360 --> 00:38:43.039
And I I think I know that there are many vendors working on that.
00:38:43.360 --> 00:38:45.760
So already shipped maybe the first version.
00:38:45.840 --> 00:38:47.760
So that that's going to be interesting to see.
00:38:47.920 --> 00:39:07.760
I I think it can be useful for any kind of person, even experienced people, because like just like things like looking up error messages, uh, you know, SQL codes, for instance, in the DB2 world, is today I go googling and I Google a what's uh you know minus six oh three or whatever, and then what is it and how do I solve it?
00:39:08.079 --> 00:39:10.800
So I I think everybody's going to use it.
00:39:10.960 --> 00:39:22.719
Uh that's sort of the information retrieval aspect of it, like hey, show get me some information, some generic information, but then you get into things like um, you know, how is my db2 doing?
00:39:22.800 --> 00:39:24.320
You know, do I have any problems?
00:39:24.400 --> 00:39:25.519
Um, these kind of things.
00:39:25.679 --> 00:39:38.880
Then you get into sort of more the AI agent world where you get information that is specific for your DB2 subsystem, and then you can combine that with the the general information, and then sort of the final step there is actually taking actions.
00:39:39.280 --> 00:39:43.599
You might you might ask the AI, you know, do any tables need a reorg?
00:39:43.679 --> 00:39:48.800
And it says, Oh, these five table spaces need a reorg, and then it's it asks us, should I run a reorg?
00:39:48.880 --> 00:39:50.320
Yeah, yes, sure, run a reorg.
00:39:51.360 --> 00:39:51.679
Yeah.
00:39:52.400 --> 00:39:57.280
It might be a while before we get there, but uh the technology is certainly there.
00:39:57.519 --> 00:40:01.119
So the the AI agents can can do these things in other areas.
00:40:01.280 --> 00:40:09.199
But I think in general the mainframe community may be more conservative, uh, so they they uh might be a bit behind on that.
00:40:09.280 --> 00:40:12.800
Uh but I I think eventually it it it will get there.
00:40:13.360 --> 00:40:19.599
And obviously a lot of us we have like a JCL library with all kinds of JCL for all kinds of things, but yeah.
00:40:19.840 --> 00:40:29.760
It might just be easier if you can, yeah, run the reorg, and I don't have to find my my uh JCL, not the reorg and uh and set the right options and so on.
00:40:29.920 --> 00:40:34.400
So I I do think it has great potential, but it's it's early days right now.
00:40:34.719 --> 00:40:40.400
Yeah, and it would I think now or soon in the future it would be fine in the non-production environments.
00:40:40.559 --> 00:40:48.800
It's just taking it to the production environment and and the potential risks or just the fear of doing that kind of thing.
00:40:48.960 --> 00:40:57.039
Because probably a regular reel can run alongside stuff at a quietish time and it will probably be fine.
00:40:58.000 --> 00:41:07.199
But uh I think that's where you kind of combine all of these things.
00:41:07.360 --> 00:41:21.599
Um I I talked about the utility history, and so so maybe you it says, Oh, you know, you you need to run Reorg on these five tables, and then it could use the utility history and say, you know, last time it took two hours, uh, so you just you know you know how long time it will run.
00:41:21.760 --> 00:41:28.480
Then you then it would ask you and say uh build the the the utility statement and say this is what I'm planning to run.
00:41:28.719 --> 00:41:42.239
Do you think that's you know so I think there'll be a lot of confirmation steps and there's a lot of information we can augment into such a flow to make the the user sort of trust the process and and still be in in control.
00:41:42.639 --> 00:41:51.840
Um it'll be a while before we see like agents go off on their own and and then figure out whatnot reorgs need to be done and then go run them, etc.
00:41:52.400 --> 00:41:59.840
Yeah, because it's also gonna need knowledge about the personal accounts application needs to be online between these hours.
00:41:59.920 --> 00:42:02.400
So you can't run anything between those hours.
00:42:02.480 --> 00:42:07.199
And you've got a maintenance window at this point, and if I start now, then the reorg is likely to finish in that maintenance window.
00:42:07.280 --> 00:42:09.280
So do you want me to run it now and it will be okay?
00:42:09.519 --> 00:42:09.760
Yeah.
00:42:10.000 --> 00:42:12.719
And yeah, I guess it needs it needs that knowledge as well, doesn't it?
00:42:12.880 --> 00:42:24.079
Not just a DB2 and not just about the the stats from what's happened in the past, but it needs that insight about the applications and the company and what's acceptable and what's not.
00:42:24.480 --> 00:42:24.880
Right.
00:42:25.039 --> 00:42:26.960
And and that that's possible.
00:42:27.519 --> 00:42:27.840
Yeah.
00:42:28.079 --> 00:42:36.239
Well, and I mean if that information is available in that in that company and it's available to those agents, it can go find it.
00:42:36.400 --> 00:42:40.000
Like is if it's on a wiki or internal website, this kind of information.
00:42:40.079 --> 00:42:46.239
It so that that's it's uh I I think in other domains you can kind of see what AI can do.
00:42:46.400 --> 00:42:53.280
Uh and so I I think we just have to be uh innovative and then uh um yeah.
00:42:53.519 --> 00:43:16.719
But yeah, though it'll the mainframe community is more conservative, so it it'll be a slower than on other uh other domains, but I think we will eventually the mainframe community is more conservative than others, and within the conservative mainframe community, I think DBAs and sysprogs are even more conservative.
00:43:17.039 --> 00:43:34.400
So I remember not long after I started working on DB2, which was DB2 2.3, so 3.1, 4, DB2 version 4, uh, we had to let users into the you know behind the gates and actually use spoofy for the first time.
00:43:34.639 --> 00:43:51.599
We were like, what would happen if we let users run actually run SQL against our database and not you know using predefined programs or or writing applications to get the data, which we could, as DBAs, we could analyze the uh the access paths.
00:43:51.760 --> 00:43:53.519
I mean, they could run anything.
00:43:53.840 --> 00:43:54.079
Yeah.
00:43:54.320 --> 00:43:59.679
We're sort of used to now people actually using spoofy and QMF and dynamic S.
00:44:00.159 --> 00:44:00.880
SQL.
00:44:01.119 --> 00:44:10.559
So it'll it'll come a point where we'd we'll say, w what would happen if you allow AI agents to actually access DB2 tables?
00:44:10.719 --> 00:44:13.039
They could run SQL and everything.
00:44:13.440 --> 00:44:19.760
Well I I have at least one customer that is writing an agent to run SQL for an application area in production.
00:44:24.239 --> 00:44:25.599
They told me about the project.
00:44:25.679 --> 00:44:27.039
It was it's really, really cool.
00:44:27.440 --> 00:44:31.519
If if they get that on Rails, I I I'm I want them to submit that for iDoc.
00:44:31.679 --> 00:44:33.760
I don't know if it'll be this year or the year after.
00:44:34.000 --> 00:44:44.079
But they they they have a really cool um sort of uh process for they they they have the same concerns but they've kind of add the QA part of that process.
00:44:44.239 --> 00:47:12.719
So uh LLMs are quite good at generating SQL uh if you give them the DDL right so you give them the DDL they can generate a query quite easily um but then you don't know if it's a good query you know does it have all the right uh conditions in the join etc but then that then they're tooling to to do that QA part etc so they have like a quite nice pipeline um with a lot of uh sort of steps to to check the quality of the SQL and then um and then run it eventually um just through a chat interface uh but I that would look very cool to me so uh so I I think it's closer than we actually think um yeah maybe maybe yeah yeah I'll look forward to hopefully seeing that sometime soon or hearing about it at least so moving on a little bit you live in the Kingdom of Denmark what does a Dv2 geek do for his his time off when he's not working does he get any time off um yeah yeah I I do get time off yeah for many years uh I did uh triathlons oh then I I crashed on my bike and broke a hip that that kind of uh ended my running career um and then COVID ended my swimming career oh no uh uh and then so so now I'm and now I'm sort of just cycling uh so crashing the bike didn't end your cycling career no interestingly enough it did not end my cycling career I I was back on the bike I don't know half a year later that that was that was fine that must have been very painful though broken hip ouch uh well yes it was was painful um but I mean it did yeah well bad things happened uh it was kind of my own fault so that there's nobody else to to blame um and I it actually happened in in France my wife was not too happy because she had to drive home from France with our caravan and I I I flew home and and and she has forbidden me to go back to the French Alps um so since then I've only gone exclusively gone to the Italian Alps so for cycling because it's a massive difference.
00:47:12.960 --> 00:48:08.719
Yeah yeah totally difference wow oh that's that's quite a cool hobby though proper big mountain cycling I I do combine it with uh with with travel so I'll sometimes bring my bike when it when I can or rent a bike locally so uh for instance uh last October I was at the the IBM Tech Exchange conference the big conference in Orlando so I I rented a bike and and went out for uh a couple of days biking in the area attended some share conferences or been biking in Kansas and yeah all kinds of other interesting places it's it's a nice way to get out to see something else than just sort of the center of a city where the conference conferences that's very cool and especially when you travel somewhere in the winter like for instance Orlando it's it's the weather is significantly better than in Denmark in the winter time.
00:48:09.599 --> 00:49:26.320
Yeah yeah we feel your pain yeah so that's what I what I spend most of my spare time on right well so you keep pretty fit then that's good yeah fairly fairly I would say uh I do try to run occasionally running is so much easier when you're on business travel because it's easy just to bring a pair of running shoes um but my my running is is extremely slow some might call it walk probably still faster than us so likely yeah so this is uh this has been great to have you on uh on our podcast and we look forward to meeting you later on in the year in Porto yeah for sure I thank you before yeah maybe before P Doug or GSC Nordic or Escueladria where so I think Esquilla Adra is the same week as GSC Nordic and I yeah believe I'm going to GSC Nordic so I'm going to Helsinki instead of Croatia right it'll be beautiful it'll be lovely might not be as warm but it'll be lovely.
00:49:26.559 --> 00:50:02.719
Right uh yeah I'm I might be at the at the police DB2 user group I think it's Gdansk in in June if I remember right yeah yeah I think I have something three weeks in a row in June uh conferences there so it's gonna be a busy month for all of us I think yeah well we'll look forward to seeing you um at those conferences and thank you so much for for everything that you do for DB2 and for the iDug community and for the local user groups and thank you very much for sharing your time with us this morning and and some of your your stories and your history it's been very very interesting yeah yeah thank you and thank you for for inviting me.
00:50:03.039 --> 00:50:12.559
You're welcome visit iDug.org for the latest DB2 community news, information about events and all of our technical content.
00:50:12.800 --> 00:50:17.760
Tune in again soon for the next podcast at idog.org forward slash podcast
00:00:08.000 --> 00:00:09.119
Hi everyone.
00:00:09.279 --> 00:00:15.519
Thanks for joining us for this series of iDug Podcasts, where we speak to some great people in the DB2 community.
00:00:15.679 --> 00:00:16.960
I'm Marcus Gavage.
00:00:17.120 --> 00:00:20.640
And I'm Julia Carter, and we represent the iDug Content Committee.
00:00:20.800 --> 00:00:22.879
We hope you enjoy today's edition.
00:00:32.560 --> 00:00:39.920
Joining us in the studio today, we have Juren Tissen, who's the Senior Technical Staff Member at Rocket Software.
00:00:40.159 --> 00:00:40.719
Welcome.
00:00:41.119 --> 00:00:41.600
Welcome.
00:00:41.920 --> 00:00:43.759
Yeah, thank you for having me.
00:00:44.240 --> 00:00:49.840
I'm a longtime listener of your of your podcast, so it's uh nice to be here.
00:00:50.159 --> 00:00:51.359
Laura, great to have you.
00:00:51.439 --> 00:00:54.560
And are you our first Rocket person?
00:00:55.280 --> 00:00:56.000
I think you might be.
00:00:57.520 --> 00:01:00.799
Yeah, that's probably well, you had uh Anthony a while ago.
00:01:00.880 --> 00:01:03.439
He he had a brief stint at Rocket Software.
00:01:03.759 --> 00:01:04.879
That's true, yeah.
00:01:04.959 --> 00:01:05.280
Yeah.
00:01:05.439 --> 00:01:08.079
But current employee, I think you're our our first.
00:01:08.319 --> 00:01:08.959
Yeah, thank you.
00:01:09.280 --> 00:01:15.519
Laura, it's good to have you here, and we're excited to hear about your life with and without DB2.
00:01:16.000 --> 00:01:17.040
So where should we start?
00:01:17.519 --> 00:01:19.920
Right at the beginning, how did you get into DBT?
00:01:20.799 --> 00:01:23.439
Well, yeah, that's kind of an interesting story.
00:01:23.599 --> 00:01:27.920
Um I I do have like a different background than than most people.
00:01:28.079 --> 00:01:32.799
Um I have actually I have a PhD in uh relativistic quantum chemistry.
00:01:33.120 --> 00:01:38.400
Yeah, I had to Google that because I read it and I thought I have no idea what it is about.
00:01:38.799 --> 00:01:39.760
Okay, what is that?
00:01:40.079 --> 00:01:55.200
Uh well well, quantum mechanics is quantum mechanics, but then sort of the chemistry part of it is really applying it to um chemistry or chemical uh problems, and then the relativistic part is really applying the the um the special relativistic theory to that.
00:01:55.519 --> 00:02:02.480
So um right now when we are recording, there's been a lot of discussion about gold and silver, like last week, if you follow that.
00:02:02.879 --> 00:02:11.520
And if if you know the periodic system with chemistry, that you know that gold and silver or silver is uh you know they're in the same column of the periodic system.
00:02:11.680 --> 00:02:15.599
So you would expect them to have similar properties, chemical properties, and so on.
00:02:15.759 --> 00:02:20.080
But you wouldn't you know that silver is silver colored and gold is gold-colored.
00:02:20.319 --> 00:02:29.840
And the reason why they are a different coloring is because of the relativistic uh you know effects on on the atom because the electrons are moving close to the speed of light.
00:02:30.000 --> 00:02:34.639
Uh so that's kind of the very short explanation of that.
00:02:34.800 --> 00:02:34.960
Uh.
00:02:36.080 --> 00:02:40.639
And didn't you do didn't you do a degree in chemistry as well?
00:02:41.039 --> 00:02:46.159
Yeah, so I I well I have a master's degree in chemistry first and then the PhD subsequently.
00:02:46.319 --> 00:02:50.479
Um, chemistry was your passion.
00:02:51.280 --> 00:03:01.680
Um it started out being chemistry, but then when I had like experimental chemistry in the lab, uh I would normally ruin for like thousands of pounds of equipment every time.
00:03:01.919 --> 00:03:07.680
And my lab coat was like full of uh holes from when I spilled you know assets and whatnot.
00:03:08.080 --> 00:03:17.520
So at some point, I I don't know if it's if it was me or somebody else sort of pointed me towards a theoretical chemistry rather than the experimental chemistry.
00:03:19.360 --> 00:03:22.479
You sound like a stereotypical mad professor then.
00:03:23.039 --> 00:03:24.159
Uh yes, yeah.
00:03:24.400 --> 00:03:29.199
My lab coat was like green and blue and red, and and yeah, that was not not good.
00:03:29.280 --> 00:03:29.759
Yeah.
00:03:30.000 --> 00:03:41.120
So it is chemistry, but I kind of found that uh theoretical chemistry is like one-third math, one-third computer science, and then one-third physics, so it was very little chemistry.
00:03:41.280 --> 00:03:52.319
Uh and most of my time I spent coding uh Fortran 77 uh programs, sort of implementing the the physical formulas in in Fortran 77.
00:03:52.719 --> 00:03:53.199
Oh wow.
00:03:54.000 --> 00:04:00.560
Running on you know, cray um machines and silicon graphics and IBM AIX and so forth.
00:04:00.800 --> 00:04:05.520
So that was how I got into sort of the IT uh IT part of it.
00:04:05.759 --> 00:04:18.800
Then while I was uh studying at university, I started playing backgammon and uh I joined the open source backgammon project, um, GNU Backgammon um that were writing an open source backgammon uh program.
00:04:18.959 --> 00:04:23.199
This was written in C, so that was how I sort of became proficient in C.
00:04:23.920 --> 00:04:29.600
As a side note, uh GNU backgammon was based, the engine was based on neural networks.
00:04:29.759 --> 00:04:31.519
So this was very early days.
00:04:31.680 --> 00:04:41.680
The the the brain of GNU Beggammon had a an N well today LLM type thing with I think like 10,000 parameters.
00:04:41.920 --> 00:04:47.120
No, today's LLMs or neural net, they have like 100 billion or one trillion parameters.
00:04:47.199 --> 00:04:49.279
So it was it was in the very early days.
00:04:49.439 --> 00:04:53.439
Uh so I worked with neural nets before it became cool.
00:04:54.399 --> 00:04:54.879
Well done.
00:04:55.839 --> 00:04:59.120
Some would argue that it's always been cool, but yeah, yeah, yeah.
00:04:59.759 --> 00:05:03.680
So you got your PhD in relativistic quantum chemistry.
00:05:04.000 --> 00:05:04.319
Yeah.
00:05:04.720 --> 00:05:05.439
Say what?
00:05:05.920 --> 00:05:11.839
Well, so so I'd done a lot of the coding in C, uh both at university and then uh in that open source project.
00:05:11.920 --> 00:05:14.480
And then IBM was looking for C programmers.
00:05:14.720 --> 00:05:21.519
They did mention some weird platform in the uh job advert, but I did a platform I knew nothing about.
00:05:21.680 --> 00:05:24.480
But I knew C, so you know how hard can it be?
00:05:25.360 --> 00:05:28.079
And that weird platform was uh MVM.
00:05:28.319 --> 00:05:30.079
Yeah, it was IBM mainframe.
00:05:30.160 --> 00:05:33.439
Uh so I I knew nothing about the mainframe then.
00:05:33.600 --> 00:05:45.439
Um but I started in IBM as uh like a junior developer or trainee or whatever you call it back in in 2001, writing C programs on this weird platform to make it even weirder.
00:05:45.519 --> 00:05:48.480
Sort of the transaction manager was IMS GM.
00:05:48.720 --> 00:05:51.920
Uh but the the database was was db2.
00:05:52.160 --> 00:05:56.399
Um but don't tend anyone that I know anything about IMS.
00:05:57.519 --> 00:05:59.680
Don't worry, your secret safe with us.
00:06:01.199 --> 00:06:07.120
So so that was kind of how I uh started on on mainframe, really as an application developer.
00:06:07.439 --> 00:06:17.360
This was like IBM's internal IT, we were creating uh internal applications, but yeah, they were running on mainframe, IMS, TM, and DB2 as the database engine.
00:06:18.079 --> 00:06:22.959
Then over time it within that application, I became the application DBA.
00:06:23.040 --> 00:06:30.560
So that was kind of how I made it into sort of more the the DBA or or more DB2 side uh of things.
00:06:30.879 --> 00:06:42.959
Then fast forward a number of years, I think it was late 2009, uh, my manager said that they were looking for a DB2 expert in the in the in the IBM sales organization, like a pre-sales specialist.
00:06:43.279 --> 00:06:51.839
And so I I moved over uh yeah, probably late 2009 or early 2010 and and became a pre-sales specialist.
00:06:52.079 --> 00:06:59.120
So kind of a switch because I had I had the application background rather than sort of a system system DBA background.
00:06:59.279 --> 00:07:02.240
So I did have to learn a lot of things.
00:07:02.560 --> 00:07:25.600
Luckily, I got one of those uh CPDTs, like the mainframe emulators, and I that was uh I I I can hear right now that there's some discussion about IBM removing it, but uh for me back then it was really a good source of of education because you had your own system, and if you screw something up, you would just sort of start from scratch and and try again.
00:07:25.839 --> 00:07:30.399
So that's that's kind of how I learned initially sort of this the system side of things.
00:07:30.639 --> 00:07:38.879
So I I think I ended up knowing too much about SMS and REGF and all kinds of other things mainframe related from from that CBDT.
00:07:39.040 --> 00:07:45.920
Uh because you when you run the CBDT for half an hour, then you know SMF runs full or Jess runs full or whatever.
00:07:46.000 --> 00:07:50.000
So you kind of had to learn a lot of uh systems programming to to keep it running.
00:07:50.319 --> 00:07:52.079
That's when you become dangerous.
00:07:52.480 --> 00:07:53.120
Yeah.
00:07:53.519 --> 00:07:53.920
Yeah.
00:07:54.160 --> 00:07:56.720
Yeah, I I know enough to be dangerous.
00:07:58.160 --> 00:08:02.399
And that that's also kind of how I came into the idoc world.
00:08:02.560 --> 00:08:08.160
So I was working as a pre-sale specialist, and a lot of my customers went to the idoc conferences in Europe.
00:08:08.240 --> 00:08:13.920
And so I I started going a well, probably 2010 was probably the first one.
00:08:14.000 --> 00:08:23.920
And I I can have no idea where it was, but I attended all the iDocs probably since then, maybe missed a single one in Europe at least.
00:08:24.160 --> 00:08:36.320
Um so initially I I I I went as a participant, and for me it was like a learning experience uh because I I was new sort of in the system side of DB2 and the engine side.
00:08:36.480 --> 00:08:42.080
So I went to all the the presentations with the iBemers back then and learned a lot about the engine.
00:08:42.639 --> 00:08:58.639
Um I I don't hope Bart Stigman's this listing, but I remember probably one of the first years I had like a whole afternoon on SMF data or you know, IFC IDs in DB2, and that was probably a bit over my head at at that time, so I think I almost fell asleep.
00:09:02.799 --> 00:09:05.279
A few hours of that, yeah, I can I can understand.
00:09:05.600 --> 00:09:06.159
Yeah.
00:09:06.399 --> 00:09:11.039
Um, but uh it was really good education for me uh back then.
00:09:12.000 --> 00:09:22.720
Going back to my open source sort of um uh contributions, that was kind of uh where I started with sort of um you know community contribution or what you would call it.
00:09:22.799 --> 00:09:28.639
Uh we had a mailing list and I would participate, and that's how I ended up sort of coding on the project as well.
00:09:28.879 --> 00:09:41.519
Back then, at some point, I I joined the IDoc list um and sort of at some point I can't remember exactly when started contributing and answering questions or participating in the um in the discussions, etc.
00:09:41.759 --> 00:09:48.559
So obviously, I I think that that's also good education, sort of to participate in in the discussions.
00:09:48.720 --> 00:09:49.600
You learn something, you know.
00:09:49.679 --> 00:09:52.000
If you write something, it's wrong, somebody will correct you.
00:09:52.960 --> 00:09:57.519
As long as it's constructive, then I think that's that's very good as well.
00:09:58.240 --> 00:10:07.919
Yeah, and it's it's good that you bring that up because whenever I search for something and it's the the DB2L as it used to be, your name is always there in the conversation.
00:10:08.000 --> 00:10:09.519
So you're always contributing.
00:10:09.600 --> 00:10:17.200
And it must take quite a lot of time to be constantly checking and and adding to that, but your contributions are really valuable.
00:10:17.600 --> 00:10:18.639
Yeah, thank you for that.
00:10:18.879 --> 00:10:31.039
Um well, yes, it is time, but I I I still see a lot of it as education because if if somebody is asking that question on the IDOC list, you know, I might get the same question from a customer at some point.
00:10:31.120 --> 00:10:34.559
And so it's in a lot of cases it is valuable.
00:10:34.879 --> 00:10:38.080
Or it might be something that a customer already asked me, so I already know the answer.
00:10:38.159 --> 00:10:40.000
So it's just a matter of writing it.
00:10:40.559 --> 00:10:41.440
Sharing it, yeah.
00:10:41.679 --> 00:10:42.240
Yeah, yeah.
00:10:42.480 --> 00:10:52.559
So but I I think in general it's it's very valuable to participate in communities like that, um, you know, for yourself but also for the the ones that wrote the question.
00:10:52.720 --> 00:10:55.679
Um so yeah, and you speak now.
00:10:55.759 --> 00:11:16.240
I mean, you say you started in 2010 and you were there to learn, but now you speak in every conference all around the world, and your sessions are always really well attended, and I think you get a lot of engagement, and I think people take a lot from your sessions because of the way, the unique way that you can explain things so that everybody gets it.
00:11:16.559 --> 00:11:17.679
Yeah, thank you for that.
00:11:17.919 --> 00:11:26.320
Uh yeah, so as I mentioned, I started participating in iDoc, and then at some point I can't remember when I started submitting presentations.
00:11:26.480 --> 00:11:30.879
I I always kind of had an interest in sort of new stuff that's come along.
00:11:31.039 --> 00:11:34.720
So that's has frequently been the topic of my presentations.
00:11:34.879 --> 00:11:42.720
Or it's somebody that's a customer, something that a customer asked about, and I had to do a lot of research and then I kind of make that into a presentation.
00:11:42.960 --> 00:11:49.759
So I I presented on sort of newer things like your Python, pipelines, Ansible, and and so on and so on.
00:11:49.840 --> 00:11:56.399
Um so that's you know, from a personal point of view, it's it's always nice to learn something new, sort of keep you fresh.
00:11:56.480 --> 00:12:05.120
Uh so I like to spend some time on on learning new topics that that come along in in the in the db2 area or sort of around it.
00:12:06.399 --> 00:12:11.840
And with Python, I actually learned Python back at at university as well, many, many years ago.
00:12:12.000 --> 00:12:14.240
Python is quite an old language as well.
00:12:15.759 --> 00:12:18.399
But it's it's it's becoming more and more popular.
00:12:18.799 --> 00:12:21.919
You were doing it at university, so that was a few years ago.
00:12:22.000 --> 00:12:23.519
Um late nineties, yeah.
00:12:23.679 --> 00:12:26.480
So yeah, I didn't realize it would be around that long.
00:12:26.960 --> 00:12:30.159
Python was written in around 1990, something like that.
00:12:30.320 --> 00:12:32.080
Uh the early 90s.
00:12:32.399 --> 00:12:32.960
Yeah.
00:12:33.279 --> 00:12:33.679
Yeah.
00:12:33.840 --> 00:12:43.200
So because I had an interest in IT, I I actually took some parts of the sort of the computer science curriculum at university, even though I was a chemist.
00:12:43.519 --> 00:12:53.200
Um, and and we a lot of the um they were using Python for a lot of the courses there, uh, like algorithm theory and so on.
00:12:53.360 --> 00:13:02.000
Uh I I did one on assembler programming and and I did one where we use C, so I kind of that's where I learned some of those programming languages.
00:13:02.159 --> 00:13:12.320
Um then Python was kind of dormant for me for many years, and then it kind of because it sort of became useful in the mainframe world, it's kind of where I picked up the interest again.
00:13:12.480 --> 00:13:15.279
So I have like a 15-year gap, Python gap.
00:13:17.120 --> 00:13:20.879
But luckily, yeah.
00:13:21.200 --> 00:13:23.919
Um yeah, it's it's becoming more popular now.
00:13:24.080 --> 00:13:30.000
Um uh you know, with younger people that do not necessarily want to or have to learn REX.
00:13:30.799 --> 00:13:34.720
Now for some things Python is a is a nice replacement.
00:13:34.960 --> 00:13:36.399
Um I I like it a lot.
00:13:36.639 --> 00:13:47.679
It's very it's very flexible, and there's a lot of libraries of modules you can you can pick and you know you know, passing JSON or YAML is like one line of code.
00:13:47.759 --> 00:13:50.320
I I would hate to write that in REST.
00:13:50.720 --> 00:13:52.559
Yeah, I wouldn't like to do that in REX.
00:13:53.759 --> 00:14:07.679
I'd like to take this opportunity to thank you personally for helping me with Python and trying to get it working, talking to DB2 using the uh IBM DB2 libraries on the mainframe and talking to the mainframe.
00:14:07.919 --> 00:14:11.360
Because I've just recently been mucking around with Python.
00:14:11.600 --> 00:14:14.480
And it's uh yeah, you've been very very helpful.
00:14:14.559 --> 00:14:15.200
So thank you for that.
00:14:15.679 --> 00:14:17.440
Everything's up and running and working now.
00:14:17.840 --> 00:14:23.519
Yeah, it it's a bit complicated and and it's somewhat different from running it on, let's say, your laptop.
00:14:23.759 --> 00:14:28.080
Yeah, just like yesterday that was I had a question from another customer.
00:14:28.399 --> 00:14:34.559
Came internally that somebody had asked one of our about one of our products and Python and IBMDB.
00:14:34.639 --> 00:14:38.240
So there's there's a lot of interest in that uh and and Python in general.
00:14:38.480 --> 00:14:44.240
Maybe I should sort of dust off my original Python and IBMDB presentation and and resubmit.
00:14:44.399 --> 00:14:55.039
Uh I think it was recorded for iDoc North America and it's out there on YouTube and it's I would say 90% still valid, but there's a few things and a few improvements since then.
00:14:55.200 --> 00:14:57.679
So yeah, sounds good.
00:14:58.399 --> 00:15:01.600
Yeah, that on the agenda for Porto, maybe.
00:15:01.919 --> 00:15:02.559
Yeah, yeah.
00:15:02.960 --> 00:15:04.720
Maybe I maybe I'll do that.
00:15:05.279 --> 00:15:24.080
Do you think that the the modernization piece that we're all faced with at the moment is one of the bigger challenges of your customers at the moment in the fact that there are people that want to do it that are almost pushing for it, but there is quite maybe resistance to to actually go with it.
00:15:24.480 --> 00:15:26.559
Yeah, I think that's exactly right.
00:15:27.919 --> 00:15:35.120
I I think a lot of customers struggle just to keep the lights on on their shop and they don't really have time to look at other things.
00:15:35.360 --> 00:15:46.960
But uh on the other hand, if you want to attract um new uh younger people to the platform, I I think we need to have some alternatives to to ISPF and and batch.
00:15:47.519 --> 00:15:52.240
So I I don't see ISPF going away anytime soon.
00:15:53.519 --> 00:16:03.360
Not in not in my lifetime, maybe, but uh I I do see like a a shift and an interest uh towards more modern interfaces.
00:16:03.679 --> 00:16:20.240
But of course, uh a lot of the products that we we all work on in the db2 tool space, they have no 20, 30 years of legacy and it's 1,000 functions, and it's really, really hard to make every single function and all of the options available in a modern UI.
00:16:20.320 --> 00:16:26.320
So that's yeah, but that is a challenge that's going to be a challenge for the future.
00:16:26.799 --> 00:16:35.120
And Zoe, as part of the open mainframe project, is making uh a good dent in that respect.
00:16:35.519 --> 00:16:42.320
Yeah, yeah, Zoe and there are many other things uh that are trying to you know add those modern interfaces.
00:16:42.480 --> 00:16:47.519
So yeah, at some point you know we we need to have everything available in a different way.
00:16:47.600 --> 00:17:02.399
And it can be web UIs for some features, or the features is more API that you can consume from, say, a Python program, or you can write your own sort of integrations, might be CLIs, you know, all kinds of interfaces that allow you to perform things.
00:17:02.639 --> 00:17:08.079
You can all you're all starting to see you know Python libraries for some features.
00:17:08.240 --> 00:17:20.880
IBMDB is obviously one thing, but now there's also SDSF available as a Python library, so you kind of get more and more functionality available, you know, some modern way, you know, API libraries or whatever.
00:17:20.960 --> 00:17:21.039
Yeah.
00:17:21.200 --> 00:17:23.920
So you can you can build your own integration.
00:17:24.240 --> 00:17:26.160
Uh I think it's also good.
00:17:26.400 --> 00:17:35.920
Maybe in the past, customers would either be, you know, BMC or Broadcom or IBM, but with APIs, you can kind of mix and match and get the best of everything.
00:17:36.160 --> 00:17:46.160
Even though we might prefer to have one specific stack, uh, I think it's still it's valuable for customers to be able to mix and match and even have like open source components at as part of that.
00:17:46.559 --> 00:17:47.680
Yeah, that's a really good point.
00:17:47.839 --> 00:17:57.680
It does add that flexibility, doesn't it, potentially to to pick and choose the best or the most applicable bits to what you're trying to achieve or the problems you're trying to resolve.
00:17:58.079 --> 00:17:58.400
Yeah.
00:17:58.640 --> 00:18:11.519
I have seen uh threads on community forums where people have been saying, yeah, but you can't write ISPF panels in in Python, but you can in REX.
00:18:12.640 --> 00:18:19.359
Well, then the question is if you need ISPF panels, you can easily create text-based UIs in Python.
00:18:19.680 --> 00:18:22.720
Then you would run it in in uh in ZOS Unix instead.
00:18:22.960 --> 00:18:27.039
But yes, it would not be ISPF, uh, it would be a different text UI.
00:18:27.680 --> 00:18:30.079
But it it may or may not be possible.
00:18:30.319 --> 00:18:37.279
Maybe customers or some users prefer web UIs and others they prefer more more CLI-based uh operations.
00:18:38.000 --> 00:18:44.160
So I I don't know if I I buy that that there's no ISPF in Python.
00:18:44.240 --> 00:18:45.920
I I don't I don't think it's necessary.
00:18:46.160 --> 00:18:46.480
Yeah.
00:18:46.880 --> 00:18:54.319
It's the change of mindset though that hey, I have this nice ISPF panel, and now I want to have the same, but with Python at the back, and well, no, sorry.
00:18:54.480 --> 00:18:58.160
You'd either have to write a web UI or text uh UI.
00:18:58.720 --> 00:19:00.240
I I have great success.
00:19:00.400 --> 00:19:02.960
Uh you call it wipe coding.
00:19:03.119 --> 00:19:04.960
Uh use Copilot for Python.
00:19:05.039 --> 00:19:06.400
It's it's very good at Python.
00:19:06.480 --> 00:19:12.160
Uh and I I just say, hey, give me a web UI, this and this and this, and it'll write the code for me.
00:19:12.480 --> 00:19:22.880
So you can you can you can quickly create uh you know not production level code, but at least some prototypes to see how it how it might look like and and work.
00:19:23.839 --> 00:19:35.440
So as a as a former developer that had like a 15-year gap in my development, I did not do much development, then having tools like that to help me is is very, very useful, I find.
00:19:35.680 --> 00:19:36.000
Yeah.
00:19:36.240 --> 00:19:44.880
I don't know, maybe I'm 90% vibe coding, so I just ask Copilot and then I'm making small modifications to the to the resulting code.
00:19:45.440 --> 00:19:48.559
I've played around with um vibe coding.
00:19:48.799 --> 00:19:55.519
Uh can't stand the term because it goes against decades of uh software engineering training.
00:19:55.759 --> 00:20:04.960
Uh but just uh to just to talk to something which has got full access to uh everyone's libraries and everybody's bad code.
00:20:05.359 --> 00:20:09.759
Uh I have had good experience with it, and it is it is good fun.
00:20:09.920 --> 00:20:14.240
And I've churned out some really good Python programs which access db2.
00:20:14.960 --> 00:20:15.920
Yeah, exactly.
00:20:16.000 --> 00:20:28.720
Um I I had a customer request come in, and they they from one of the tools we do for IBM, they wanted to have some an a new report or a new layout of an existing report, and and they wanted to save it in a db2 table.
00:20:28.799 --> 00:20:36.319
And I I I created a prompt in Copilot and it spit out 200 lines of Python code, and I had to make two modifications.
00:20:36.480 --> 00:20:50.480
Um the the DDL was embedded and it had like a syntax error in the DDL, and then going back to the IBM DB module, it was using like a distributed connection string to DB2, and I wanted to run it on ZOS Unix, so I had to change the connection string.
00:20:50.640 --> 00:20:58.400
But the program ran and it passed the report, put it into a DB2 table, and it was like five minutes of of work for me.
00:20:58.799 --> 00:20:59.119
Yeah.
00:20:59.759 --> 00:21:06.400
Uh so I I see it, it's very powerful for sort of prototyping or one-offs of these kind of things.
00:21:06.799 --> 00:21:09.599
Yeah, I guess you need the attitude though, don't you?
00:21:09.759 --> 00:21:12.640
It's not like this can do my job for me.
00:21:12.960 --> 00:21:13.279
No.
00:21:14.319 --> 00:21:25.920
It's just got to be like the basis or to help generate the ideas and the initial stepping stones, and then you've got to use your your actual human elements to bring it all together.
00:21:26.240 --> 00:21:27.119
Right, yeah.
00:21:27.279 --> 00:21:29.279
I use it a lot for prototyping.
00:21:29.359 --> 00:21:35.519
Uh, so when we're looking at sort of innovation items and we want to see how this actually looks like or would it work, etc.
00:21:35.759 --> 00:21:42.079
It's you can use it sort of to quickly build a prototype, and then somebody in development will have to create something that actually works.
00:21:42.319 --> 00:21:43.359
I think that's yeah.
00:21:45.440 --> 00:21:47.279
And and test it and so on.
00:21:47.599 --> 00:21:48.480
Oh, yeah, testing.
00:21:48.880 --> 00:21:49.920
Do people still do that?
00:21:52.160 --> 00:21:53.599
Check in production, test it.
00:21:54.400 --> 00:21:56.160
Doc documentation and so forth.
00:21:56.240 --> 00:21:56.559
Yeah.
00:21:58.000 --> 00:21:58.640
Yeah.
00:21:59.039 --> 00:22:03.200
So we uh We left you in technical sales, in pre-sales in IBM.
00:22:03.920 --> 00:22:05.359
So then what happened?
00:22:05.519 --> 00:22:08.319
How did you get into Rocket and what do you do now?
00:22:08.880 --> 00:22:17.599
Um yeah, so so then uh I was there six or seven years uh and then in 2007 I I applied for a job at Rocket.
00:22:18.240 --> 00:22:26.240
Sort of just before that, uh Rocket was taking over the development, a lot a lot of the um the IBM brand, the DB2 tools.
00:22:26.480 --> 00:22:38.160
I ca I really like sort of the interaction with development, not necessarily being a developer myself, but sort of the interaction, sort of advocating on behalf of the customer, being close to development.
00:22:38.400 --> 00:22:56.000
And so I kind of wanted to be closer to development, so I I applied for a job in I don't know, late 2016, and I joined Rocket in in 2017, still kind of as a pre-sales um specialist, and then that's kind of what I am still today, although my title has has changed since then.
00:22:56.240 --> 00:23:19.119
So we help IBM at the back end with uh with pre-sales activities, post-sales, deployments, and and obviously being close to development, we we help with uh innovation and some of the new features and um being like the the customer advocate um to make sure that what we actually develop is something that the customers want and uh it's what they need.
00:23:20.160 --> 00:23:39.359
Um you know in in these days with with sort of more agile development and and uh the continuous delivery, obviously now there's there's much shorter feedback cycle compared to you know years back where you would have a new release of a product every three years, and and there will it will be much slower feedback cycle than than today.
00:23:39.519 --> 00:23:51.279
So there's a lot of interaction with customers um on new features and and what you know if we're doing the right thing and so on, including that modernization we talked about um earlier.
00:23:51.519 --> 00:23:54.960
So yeah, so that's that's what I've been doing since then.
00:23:55.039 --> 00:24:02.240
So I ended up being 16 years, I think, in in IBM and now I've been eight, nine years in in Rocket.
00:24:02.640 --> 00:24:07.279
I think I'll have 25 years of mainframe anniversary this year, I guess.
00:24:07.519 --> 00:24:07.839
Yeah.
00:24:11.039 --> 00:24:11.680
Yeah, thank you.
00:24:11.920 --> 00:24:13.519
Doesn't make you feel old, does it?
00:24:14.880 --> 00:24:18.000
Um well, yeah, I guess.
00:24:18.079 --> 00:24:28.240
I don't know if it's a positive or negative thing, but in in Denmark, uh you know, they raise the retirement age with sort of the based on your uh uh expected lifespan.
00:24:28.319 --> 00:24:31.519
So I can I can retire in at 71, I think, maybe.
00:24:31.920 --> 00:24:32.720
71.
00:24:32.880 --> 00:24:33.759
Oh my goodness.
00:24:34.319 --> 00:24:36.799
And they might put it up before you get there.
00:24:38.079 --> 00:24:39.920
So I have 20 years to go.
00:24:42.079 --> 00:24:48.720
So you've worked with gosh, you said 25 years working with the mainframe.
00:24:48.799 --> 00:25:00.960
So what do you think have been, in your opinion, the uh the big developments, the the wows of db2 and the mainframe in in those 25 years?
00:25:01.920 --> 00:25:11.920
I I think it's very difficult when you when you've been in the world, you kind of see sort of the small increments, and it's you you have really have to think about what was the major developments.
00:25:12.079 --> 00:25:22.400
Uh I as I mentioned, I like to look at new features, so that's kind of always where my focus is on sort of the the past new features.
00:25:22.640 --> 00:25:28.160
I I don't know with the actual mainframe, I think there's some major developments, it's kind of all incremental to me.
00:25:28.400 --> 00:25:32.240
But if if I look at some of the recent features, um I really like.
00:25:32.480 --> 00:25:41.519
And because I've never been a production DBA, I've I've only been an application DBA, I I never really had the responsible responsibility for a production system.
00:25:41.680 --> 00:25:45.440
I did break it as an application developer, that's a different story.
00:25:48.319 --> 00:25:58.240
Um but I sort of sort of some of the recent features I find really interesting is is the redirected uh recovery um uh feature of DB2.
00:25:58.559 --> 00:26:07.680
Uh in the past it was really impossible for customers to actually test uh recoveries now, unless they had like a DR environment where they could run these kind of things.
00:26:07.759 --> 00:26:17.680
Uh but now with the redirected recovery, you can run a recover test uh in your production environment and see, you know, demonstrate that you can actually recover.
00:26:17.759 --> 00:26:28.319
You are recoverable, figure out how long time it takes, um, and then sort of extrapolate to you know what is my um my RTO for an entire system.
00:26:28.400 --> 00:26:38.319
Um and we've seen quite many customers uh doing redirected recoveries uh and learning all kinds of interesting lessons about recovery.
00:26:38.480 --> 00:26:40.799
So I think that's I think it's a good thing.
00:26:40.960 --> 00:26:44.400
You know, we've seen customers that find out that that tape is slow.
00:26:44.480 --> 00:26:49.839
You know, if you have archive, it takes a long time to recover.
00:26:50.079 --> 00:26:55.920
Um and so the the um disk storage seller was happy after that.
00:26:57.119 --> 00:26:58.640
Yeah, of course.
00:26:59.839 --> 00:27:08.000
Um and I also think our customers found out that the R2 might be slower than they you know promised in some of their uh documents.
00:27:08.559 --> 00:27:09.440
Or they were told.
00:27:09.519 --> 00:27:14.079
I think often it's just they were told what the RTO would be, and it's like we can recover in four hours.
00:27:14.160 --> 00:27:15.279
Yeah, yeah, sure.
00:27:17.039 --> 00:27:18.240
We have no idea.
00:27:18.559 --> 00:27:19.519
Yeah, yeah, yeah.
00:27:19.759 --> 00:27:20.960
Now they have an idea.
00:27:21.759 --> 00:27:28.799
And also I uh some customers have learned sort of important operational experience with recovery because they have never done them before.
00:27:29.119 --> 00:27:31.039
You know, how do you restart a recover job?
00:27:31.119 --> 00:27:32.640
You know, what do you do when something breaks?
00:27:32.799 --> 00:27:34.000
What can break, etc.
00:27:34.400 --> 00:27:41.839
So I think for a lot of customers that has been a good way to learn without you know being in an actual recover situation.
00:27:42.400 --> 00:27:57.119
Yeah, I agree that redirected recovery is a big step forward, but for me personally, I feel like it needs to go further because some places aren't going to be happy about you running a recover job in a production environment unless it's actually an emergency and you need to do it.
00:27:57.279 --> 00:27:59.519
Because it's it there is a risk to it still.
00:27:59.680 --> 00:28:04.240
If you get one little thing wrong, it could be wrong.
00:28:04.559 --> 00:28:05.119
Very simple.
00:28:05.359 --> 00:28:12.640
Yeah, I I did have one customer that gets some got something wrong there, so that's one of the sort of the fall falls under the operational experience.
00:28:12.960 --> 00:28:13.599
Right.
00:28:14.000 --> 00:28:25.119
But I I I've I've seen some customers that are that are doing it quite well and they will set up RackF rules, etc., that prevents you from from sort of harming the production system.
00:28:25.200 --> 00:28:32.240
So there are there are some good ideas out there to make sure that you don't shoot yourself in the foot, uh, as I've seen some customers do.
00:28:32.480 --> 00:28:48.000
But I I do have some customers that have recovered 10, 20, 25% of production system over like a weekend to get really, really good estimate of of how how long time it will take to to recover their production environment in case it it uh you know they need to.
00:28:48.880 --> 00:28:51.759
So yeah, that I think that's an exercise, isn't it?
00:28:51.839 --> 00:28:58.000
I mean that's a really good undertaking because you'd have to put a load more DASD there for that.
00:28:58.160 --> 00:28:59.920
And well goodness, yeah.
00:29:00.160 --> 00:29:05.519
Just thinking about all the all the operational and practical things that you need to do in order to actually achieve that.
00:29:05.599 --> 00:29:06.960
That's that's quite a major exercise.
00:29:07.200 --> 00:29:07.759
Yeah, yeah.
00:29:08.079 --> 00:29:15.359
That particular customer, they had they had sort of capacity, at least CPU-wise, in in over the weekend, uh, so they had they they could run it there.
00:29:15.440 --> 00:29:18.400
But yes, they needed like 25% additional DASD.
00:29:19.440 --> 00:29:36.160
Um but that there's some good lessons to be learned uh of doing maybe you don't need to do 25%, maybe you can do five or ten percent, but there has to be some kind of non-trivial amount of data you recover to get, otherwise it'd be difficult sort of to extrapolate to to the full full amount of data.
00:29:36.240 --> 00:29:37.359
Uh sure, yeah.
00:29:37.519 --> 00:29:38.960
Yeah, but they're interesting.
00:29:39.680 --> 00:29:48.720
I I like I like that um feature a lot, and I I think uh those customers that have tried it out uh are also big fans of it.
00:29:49.039 --> 00:29:53.680
Um then another rather recent feature is the utility history.
00:29:53.839 --> 00:29:57.599
I know BMC has had that for for some years, but now it's in the IP.
00:29:59.200 --> 00:30:00.400
Nice to see you catch up.
00:30:00.480 --> 00:30:01.279
Well done.
00:30:02.559 --> 00:30:11.200
Yeah, I I think Hawkon Rupert has uh admitted that that has been an RFE or whatever it was called before RFEs for for quite many years.
00:30:11.279 --> 00:30:14.960
Uh but but it finally arrived in in DV2 version 13.
00:30:15.119 --> 00:30:18.960
And there's a lot of valuable data in that, you you you would know that.
00:30:19.119 --> 00:30:24.960
Uh but yeah, looking at you know uh CPU, elapsed time, etc.
00:30:25.759 --> 00:30:33.759
Have you seen customers actually using the data in uh in a positive way to provide insights into what they're doing with their utilities?
00:30:34.079 --> 00:30:39.920
Yes, and I think there have been some IDoc presentation, I believe, um, from some customers on that.
00:30:40.000 --> 00:30:42.000
Um I think from Commerce Bank.
00:30:42.559 --> 00:30:49.599
Uh I I I think I don't know if that's positive or negative, but I think some customers realized how much CPU copy is using.
00:30:49.839 --> 00:30:50.079
Oh.
00:30:50.880 --> 00:30:57.839
And so I think Hokon Robots commented on that, and they actually had to add SIP SIP uh enablement in the copy utility.
00:30:58.640 --> 00:30:59.839
Win win then.
00:31:00.160 --> 00:31:00.480
Yeah.
00:31:00.799 --> 00:31:04.720
Because now it was very visible how much CPU you were burning on image copies.
00:31:04.880 --> 00:31:05.519
Yeah.
00:31:05.839 --> 00:31:21.440
But I I think there's a lot of valuable, valuable data in the utility history uh in in terms of also if you're planning to run a utility, you know, how long time did it take last time, and you can maybe extrapolate or do more clever things with with the data.
00:31:21.680 --> 00:31:25.519
So I think that's I I think that's a very powerful feature.
00:31:25.759 --> 00:31:30.079
It is still quite new, and a lot of customers had only made it to version 13.
00:31:30.240 --> 00:31:33.119
And it is something you have to enable, obviously, through a CPAM.
00:31:33.359 --> 00:31:42.960
So but I you know we hope that once customers start collecting this data, um, we have a lot of plans sort of to to exploit that data for for various things.
00:31:43.119 --> 00:31:50.400
But uh and the nice thing is that it's you know it's collected by the customer themselves, so it's it's very environment-specific uh for them.
00:31:50.559 --> 00:31:53.680
So it's very useful data in these kind of contexts.
00:31:54.000 --> 00:31:54.640
Yeah.
00:31:56.319 --> 00:32:00.240
Then maybe that's an older feature, but the Dv2 system profiles.
00:32:00.400 --> 00:32:02.799
I I can't remember when they were came around.
00:32:03.039 --> 00:32:05.200
They are some versions old.
00:32:05.279 --> 00:32:06.640
I don't know if you can remember them.
00:32:07.599 --> 00:32:09.119
Mark's we're googling it.
00:32:09.279 --> 00:32:09.920
Yeah.
00:32:12.400 --> 00:32:13.680
Version 10?
00:32:14.240 --> 00:32:17.279
Yeah, I was thinking version 10, but it might be version 9.
00:32:17.519 --> 00:32:23.680
I I think it's a wildly underused feature uh and maybe underappreciated feature.
00:32:23.839 --> 00:32:40.079
Uh I I've gotten a lot of questions from customers that said, hey, we have this remote application connecting, and uh they had a loop and they consumed all our threads or connections, or they ran some ugly SQL, and I I have no idea who it is and where they came from, and how do I get rid of them?
00:32:40.240 --> 00:32:46.480
And you can do that with the system profiles, um, you know, penalty box or even blog applications.
00:32:46.720 --> 00:32:53.759
Um and I I I talked to several customers that basically uh penalty box every application they have.
00:32:54.079 --> 00:33:00.319
Oh, so anyone that connects, they okay, you can have five threads or ten connections, but not more than that.
00:33:00.559 --> 00:33:03.279
I I asked them, hey, hey, what if you show good behavior?
00:33:03.440 --> 00:33:05.039
Can you get out of the penalty box?
00:33:05.200 --> 00:33:05.920
Uh no.
00:33:08.160 --> 00:33:08.720
Strict.
00:33:09.039 --> 00:33:10.240
That's very strict.
00:33:10.559 --> 00:33:16.319
Yeah, but it it gives you a way sort of to proactively um protect your db2 subsystem.
00:33:16.480 --> 00:33:22.079
And I I think a lot of customers seeing the distributed workload increasing and increasing.
00:33:22.640 --> 00:33:28.000
And it's obviously the for some customers it's the wild, wild west, at least large customers.
00:33:28.160 --> 00:33:41.200
You know, they have thousands of developers, and and the DBAs have no idea who is connecting to the system, there's no control, and the system profiles give them that control and and the ability to proactively manage it.
00:33:41.519 --> 00:33:49.119
You can also set special registers, so you can set Apple Compad for applications that may not tolerate a high Apple Compad, or vice versa.
00:33:49.279 --> 00:33:55.920
Uh, if you have the uh IBM and analytics accelerator, you can you can set the special register related to that.
00:33:56.000 --> 00:34:08.079
And there's all kinds of uh interesting things you can do on the system side rather than asking you know a random developer you you have no idea who is uh to set the right parameters um at their end.
00:34:08.239 --> 00:34:12.239
So I think that's an underused feature uh and underappreciated.
00:34:12.639 --> 00:34:34.320
I I I really like that, especially when I hear some of those customer stories, both from those that have done it up front, so they kind of save the DV2 subsystem, but also when those customers I talked to that have not used it, then understand, hey, you know, I now I could actually I could uh put that user in a penalty box or even prevent them um from connecting.
00:34:34.480 --> 00:34:37.760
So um yeah, I think that's that's a very nice feature.
00:34:38.079 --> 00:34:39.280
Yeah, it's a really good point.
00:34:39.360 --> 00:34:42.239
And I don't think anyone's ever mentioned that one before when we've asked them.
00:34:42.559 --> 00:34:48.000
But I think you're right, it's underused and underappreciated perhaps and could be very powerful.
00:34:48.400 --> 00:34:49.039
Yeah.
00:34:49.840 --> 00:34:55.199
And sort of in that DB2 has added a lot of instrument instrumentation for distributed workload.
00:34:55.280 --> 00:35:01.440
Uh so you get more and more insight into what is actually connecting from what IP addresses and users and so forth.
00:35:01.599 --> 00:35:07.039
So now you kind of have you have the instrumentation and now you have the sort of the hammer.
00:35:10.000 --> 00:35:20.079
So you know, so you can kind of create some kind of monitoring and and then also uh implement uh the profiles um and and and manage your workload that way.
00:35:20.239 --> 00:35:26.639
I think that's that will become increasingly pop popular as more and more distributed workload are are coming in.
00:35:26.880 --> 00:35:32.800
It's probably there that the the highest uh sort of the the growth in workload is from distributed, I think.
00:35:33.199 --> 00:35:33.519
Yeah.
00:35:33.760 --> 00:35:42.719
So so the the last thing I thought about was the very recent feature, and so and the jury is still out whether that will be popular or not.
00:35:42.960 --> 00:35:46.239
Um that is uh open telemetry tracing.
00:35:46.639 --> 00:35:48.880
Uh right, that's quite new, isn't it?
00:35:49.199 --> 00:35:49.840
Yeah.
00:35:50.400 --> 00:36:04.559
So IBM recently shipped uh open telemetry tracing for all of the subsystems, so db2, IMS, uh KIX, Kix Transaction Gateway, uh MQ, ZOS Connect, maybe something I've forgotten.
00:36:04.800 --> 00:36:29.840
Um so it's really sort of the the sort of the holy grail of the end-to-end monitoring that everybody has has wanted for many many years, but it was very difficult to follow a transaction that originated like on a mobile phone and all the way through whatever systems, all the way down to db2, and then kind of understanding what happened and if something is wrong, who who is the culprit?
00:36:30.480 --> 00:36:33.760
Um so it it looks very promising.
00:36:34.159 --> 00:36:35.920
Uh it is a new feature.
00:36:36.079 --> 00:36:38.639
Uh customer adoption, I think, is still unclear.
00:36:38.800 --> 00:36:42.800
There are some customers that are interested in it, obviously, otherwise IBM would not do it.
00:36:43.039 --> 00:36:46.079
Um but it yeah, the jury is still out on that.
00:36:46.320 --> 00:36:59.679
I I did together with a colleague uh Christoph, we we wrote a blog on on like how do you instrument a Java program and all the way down to DB2, and you can s you can follow follow that trace and uh and see everything.
00:36:59.840 --> 00:37:04.559
And uh Christoph, my colleague, is going to submit that for for uh Porto this year.
00:37:04.639 --> 00:37:06.159
So oh that would be interesting.
00:37:06.239 --> 00:37:07.599
Yeah, it'd be good to see that.
00:37:08.000 --> 00:37:08.480
Yeah.
00:37:09.519 --> 00:37:11.760
So that's that's a very recent feature.
00:37:11.920 --> 00:37:16.400
Uh so we we will see you know how how that is uh received by by customers.
00:37:16.480 --> 00:37:18.079
Uh it is very interesting.
00:37:18.400 --> 00:37:19.039
Yeah.
00:37:19.280 --> 00:37:24.719
Um yeah, and obviously AI is is uh is interesting as well.
00:37:24.960 --> 00:37:32.880
Um IBM has shipped an an agent, DB2 agent that you can connect to to your LM.
00:37:33.119 --> 00:37:37.280
So that I've I I foresee there'll be a lot of lot of things going on in that space.
00:37:37.840 --> 00:37:41.360
It's a very hot topic across everything AI.
00:37:42.719 --> 00:37:44.000
Absolutely, yeah.
00:37:44.559 --> 00:37:50.639
So, how do you think AI will affect the role of the DBA and the sysprog going forward?
00:37:50.880 --> 00:37:55.519
What kind of changes, what kind of DBA would use AI tools?
00:37:56.159 --> 00:37:57.679
Yeah, that's a good question.
00:37:57.920 --> 00:38:02.639
Um so so personally I'm using AI a lot.
00:38:02.719 --> 00:38:07.360
Uh you know, I have Copilot home all the time, asking all kinds of questions.
00:38:07.599 --> 00:38:14.719
Um I I think like for for I mentioned Python, it's very good at write writing Python code.
00:38:14.880 --> 00:38:19.519
I I can also get some some OKJCL out for some some things.
00:38:19.679 --> 00:38:24.880
Uh but I I think mainframe is kind of um a niche area.
00:38:24.960 --> 00:38:26.320
So so I think so.
00:38:26.400 --> 00:38:32.320
I think those AI engines need to be, you know, you cannot use sort of the general ones to get good answers there.
00:38:32.400 --> 00:38:38.960
You need something on top of that, so like a mainframe-specific LLM that has some additional information.
00:38:39.360 --> 00:38:43.039
And I I think I know that there are many vendors working on that.
00:38:43.360 --> 00:38:45.760
So already shipped maybe the first version.
00:38:45.840 --> 00:38:47.760
So that that's going to be interesting to see.
00:38:47.920 --> 00:39:07.760
I I think it can be useful for any kind of person, even experienced people, because like just like things like looking up error messages, uh, you know, SQL codes, for instance, in the DB2 world, is today I go googling and I Google a what's uh you know minus six oh three or whatever, and then what is it and how do I solve it?
00:39:08.079 --> 00:39:10.800
So I I think everybody's going to use it.
00:39:10.960 --> 00:39:22.719
Uh that's sort of the information retrieval aspect of it, like hey, show get me some information, some generic information, but then you get into things like um, you know, how is my db2 doing?
00:39:22.800 --> 00:39:24.320
You know, do I have any problems?
00:39:24.400 --> 00:39:25.519
Um, these kind of things.
00:39:25.679 --> 00:39:38.880
Then you get into sort of more the AI agent world where you get information that is specific for your DB2 subsystem, and then you can combine that with the the general information, and then sort of the final step there is actually taking actions.
00:39:39.280 --> 00:39:43.599
You might you might ask the AI, you know, do any tables need a reorg?
00:39:43.679 --> 00:39:48.800
And it says, Oh, these five table spaces need a reorg, and then it's it asks us, should I run a reorg?
00:39:48.880 --> 00:39:50.320
Yeah, yes, sure, run a reorg.
00:39:51.360 --> 00:39:51.679
Yeah.
00:39:52.400 --> 00:39:57.280
It might be a while before we get there, but uh the technology is certainly there.
00:39:57.519 --> 00:40:01.119
So the the AI agents can can do these things in other areas.
00:40:01.280 --> 00:40:09.199
But I think in general the mainframe community may be more conservative, uh, so they they uh might be a bit behind on that.
00:40:09.280 --> 00:40:12.800
Uh but I I think eventually it it it will get there.
00:40:13.360 --> 00:40:19.599
And obviously a lot of us we have like a JCL library with all kinds of JCL for all kinds of things, but yeah.
00:40:19.840 --> 00:40:29.760
It might just be easier if you can, yeah, run the reorg, and I don't have to find my my uh JCL, not the reorg and uh and set the right options and so on.
00:40:29.920 --> 00:40:34.400
So I I do think it has great potential, but it's it's early days right now.
00:40:34.719 --> 00:40:40.400
Yeah, and it would I think now or soon in the future it would be fine in the non-production environments.
00:40:40.559 --> 00:40:48.800
It's just taking it to the production environment and and the potential risks or just the fear of doing that kind of thing.
00:40:48.960 --> 00:40:57.039
Because probably a regular reel can run alongside stuff at a quietish time and it will probably be fine.
00:40:58.000 --> 00:41:07.199
But uh I think that's where you kind of combine all of these things.
00:41:07.360 --> 00:41:21.599
Um I I talked about the utility history, and so so maybe you it says, Oh, you know, you you need to run Reorg on these five tables, and then it could use the utility history and say, you know, last time it took two hours, uh, so you just you know you know how long time it will run.
00:41:21.760 --> 00:41:28.480
Then you then it would ask you and say uh build the the the utility statement and say this is what I'm planning to run.
00:41:28.719 --> 00:41:42.239
Do you think that's you know so I think there'll be a lot of confirmation steps and there's a lot of information we can augment into such a flow to make the the user sort of trust the process and and still be in in control.
00:41:42.639 --> 00:41:51.840
Um it'll be a while before we see like agents go off on their own and and then figure out whatnot reorgs need to be done and then go run them, etc.
00:41:52.400 --> 00:41:59.840
Yeah, because it's also gonna need knowledge about the personal accounts application needs to be online between these hours.
00:41:59.920 --> 00:42:02.400
So you can't run anything between those hours.
00:42:02.480 --> 00:42:07.199
And you've got a maintenance window at this point, and if I start now, then the reorg is likely to finish in that maintenance window.
00:42:07.280 --> 00:42:09.280
So do you want me to run it now and it will be okay?
00:42:09.519 --> 00:42:09.760
Yeah.
00:42:10.000 --> 00:42:12.719
And yeah, I guess it needs it needs that knowledge as well, doesn't it?
00:42:12.880 --> 00:42:24.079
Not just a DB2 and not just about the the stats from what's happened in the past, but it needs that insight about the applications and the company and what's acceptable and what's not.
00:42:24.480 --> 00:42:24.880
Right.
00:42:25.039 --> 00:42:26.960
And and that that's possible.
00:42:27.519 --> 00:42:27.840
Yeah.
00:42:28.079 --> 00:42:36.239
Well, and I mean if that information is available in that in that company and it's available to those agents, it can go find it.
00:42:36.400 --> 00:42:40.000
Like is if it's on a wiki or internal website, this kind of information.
00:42:40.079 --> 00:42:46.239
It so that that's it's uh I I think in other domains you can kind of see what AI can do.
00:42:46.400 --> 00:42:53.280
Uh and so I I think we just have to be uh innovative and then uh um yeah.
00:42:53.519 --> 00:43:16.719
But yeah, though it'll the mainframe community is more conservative, so it it'll be a slower than on other uh other domains, but I think we will eventually the mainframe community is more conservative than others, and within the conservative mainframe community, I think DBAs and sysprogs are even more conservative.
00:43:17.039 --> 00:43:34.400
So I remember not long after I started working on DB2, which was DB2 2.3, so 3.1, 4, DB2 version 4, uh, we had to let users into the you know behind the gates and actually use spoofy for the first time.
00:43:34.639 --> 00:43:51.599
We were like, what would happen if we let users run actually run SQL against our database and not you know using predefined programs or or writing applications to get the data, which we could, as DBAs, we could analyze the uh the access paths.
00:43:51.760 --> 00:43:53.519
I mean, they could run anything.
00:43:53.840 --> 00:43:54.079
Yeah.
00:43:54.320 --> 00:43:59.679
We're sort of used to now people actually using spoofy and QMF and dynamic S.
00:44:00.159 --> 00:44:00.880
SQL.
00:44:01.119 --> 00:44:10.559
So it'll it'll come a point where we'd we'll say, w what would happen if you allow AI agents to actually access DB2 tables?
00:44:10.719 --> 00:44:13.039
They could run SQL and everything.
00:44:13.440 --> 00:44:19.760
Well I I have at least one customer that is writing an agent to run SQL for an application area in production.
00:44:24.239 --> 00:44:25.599
They told me about the project.
00:44:25.679 --> 00:44:27.039
It was it's really, really cool.
00:44:27.440 --> 00:44:31.519
If if they get that on Rails, I I I'm I want them to submit that for iDoc.
00:44:31.679 --> 00:44:33.760
I don't know if it'll be this year or the year after.
00:44:34.000 --> 00:44:44.079
But they they they have a really cool um sort of uh process for they they they have the same concerns but they've kind of add the QA part of that process.
00:44:44.239 --> 00:47:12.719
So uh LLMs are quite good at generating SQL uh if you give them the DDL right so you give them the DDL they can generate a query quite easily um but then you don't know if it's a good query you know does it have all the right uh conditions in the join etc but then that then they're tooling to to do that QA part etc so they have like a quite nice pipeline um with a lot of uh sort of steps to to check the quality of the SQL and then um and then run it eventually um just through a chat interface uh but I that would look very cool to me so uh so I I think it's closer than we actually think um yeah maybe maybe yeah yeah I'll look forward to hopefully seeing that sometime soon or hearing about it at least so moving on a little bit you live in the Kingdom of Denmark what does a Dv2 geek do for his his time off when he's not working does he get any time off um yeah yeah I I do get time off yeah for many years uh I did uh triathlons oh then I I crashed on my bike and broke a hip that that kind of uh ended my running career um and then COVID ended my swimming career oh no uh uh and then so so now I'm and now I'm sort of just cycling uh so crashing the bike didn't end your cycling career no interestingly enough it did not end my cycling career I I was back on the bike I don't know half a year later that that was that was fine that must have been very painful though broken hip ouch uh well yes it was was painful um but I mean it did yeah well bad things happened uh it was kind of my own fault so that there's nobody else to to blame um and I it actually happened in in France my wife was not too happy because she had to drive home from France with our caravan and I I I flew home and and and she has forbidden me to go back to the French Alps um so since then I've only gone exclusively gone to the Italian Alps so for cycling because it's a massive difference.
00:47:12.960 --> 00:48:08.719
Yeah yeah totally difference wow oh that's that's quite a cool hobby though proper big mountain cycling I I do combine it with uh with with travel so I'll sometimes bring my bike when it when I can or rent a bike locally so uh for instance uh last October I was at the the IBM Tech Exchange conference the big conference in Orlando so I I rented a bike and and went out for uh a couple of days biking in the area attended some share conferences or been biking in Kansas and yeah all kinds of other interesting places it's it's a nice way to get out to see something else than just sort of the center of a city where the conference conferences that's very cool and especially when you travel somewhere in the winter like for instance Orlando it's it's the weather is significantly better than in Denmark in the winter time.
00:48:09.599 --> 00:49:26.320
Yeah yeah we feel your pain yeah so that's what I what I spend most of my spare time on right well so you keep pretty fit then that's good yeah fairly fairly I would say uh I do try to run occasionally running is so much easier when you're on business travel because it's easy just to bring a pair of running shoes um but my my running is is extremely slow some might call it walk probably still faster than us so likely yeah so this is uh this has been great to have you on uh on our podcast and we look forward to meeting you later on in the year in Porto yeah for sure I thank you before yeah maybe before P Doug or GSC Nordic or Escueladria where so I think Esquilla Adra is the same week as GSC Nordic and I yeah believe I'm going to GSC Nordic so I'm going to Helsinki instead of Croatia right it'll be beautiful it'll be lovely might not be as warm but it'll be lovely.
00:49:26.559 --> 00:50:02.719
Right uh yeah I'm I might be at the at the police DB2 user group I think it's Gdansk in in June if I remember right yeah yeah I think I have something three weeks in a row in June uh conferences there so it's gonna be a busy month for all of us I think yeah well we'll look forward to seeing you um at those conferences and thank you so much for for everything that you do for DB2 and for the iDug community and for the local user groups and thank you very much for sharing your time with us this morning and and some of your your stories and your history it's been very very interesting yeah yeah thank you and thank you for for inviting me.
00:50:03.039 --> 00:50:12.559
You're welcome visit iDug.org for the latest DB2 community news, information about events and all of our technical content.
00:50:12.800 --> 00:50:17.760
Tune in again soon for the next podcast at idog.org forward slash podcast
