Jon Paris on DATA-INTO, the RPG & DB2 Summit, Travel to Poland and More
Paul Tuohy interviews Jon Paris of Partner400 about DATA-INTO, the RPG & DB2 Summit and more.
By Paul Tuohy04/01/2018
Paul Tuohy: Hi everybody. Welcome to another iTalk with Tuohy. Delighted to be joined today by my friend, my colleague, my mentor and all around good guy, Jon Paris. Hi Jon.
Jon Paris: Jeepers. I want a pay raise if I'm that good.
Paul: [Laughs] So as you know Jon, you've got two chances of a pay raise and slim is on a long vacation.
Jon: That's right. Yup. Yeah, I can understand that.
Paul: Jon, I was just looking here. Do you know when the last time we did an iTalk was?
Jon: I'm guessing about 12 months or so ago, but I really don't know for sure.
Paul: We're just short of two years.
Jon: Is it really?
Jon: Doesn't time fly when you're enjoying yourself?
Paul: Indeed [laughs]. Also enjoying yourself is not talking to me. Okay. Got you. Okay.
Paul: I know where this is going now.
Jon: Actually I think it's the phrase flying when you're enjoying yourself just came to mind because that was title we put for the blog this―recent blog so―
Paul: Oh, okay.
Jon: It's just fresh in my mind. What can I say?
Jon: No insult intended, my friend.
Paul: Well that's a first [laughs]. Okay so Jon, tell me: What have you been playing with recently?
Jon: The-I heard your interview with Barbara [Morris], during which she said that, you know, I've been playing with DATA-INTO, which I love. I haven't been able to spend as much time since the initial flush, if you like, on it as I want to, but it is a really powerful bit of tooling and I'm absolutely thrilled that Barbara is getting the resources to do these kind of extension things. These are the things I think that are going to be the future of RPG. You know we don't need IBM to produce something that would you know―I can't think of anything off the top of my head―but you know, a new version of TRIM or something, you know?
Jon: Stuff we can write ourselves, we don't need IBM for. What we need is bridges into it so that we can use RPG's data handling but at the same time get into new functionality and that we can drive that through third parties. We can write it ourselves or drive it through third parties, so this is kind of a logical evolution in that sense of what happened with Open Access. You know this is kind of Open Access meets XML-INTO, really.
Paul: Right. So tell me, Jon―
Jon: Because you―
Paul: Just from a technical point of view on it then: Would you say that DATA-INTO is closer to XML-INTO or closer to Open Access?
Paul: [Laughs] Well thank for that, Jon.
Jon: You're welcome. It is basically closer to XML-INTO in the way that you build the associations between the names of the data items you're handling and the data structures that will get populated from them. So it's the same basic name to name and hierarchy for hierarchy mapping.
Jon: So it's very much like XML-INTO in that regard, but the differences whereas with XML-INTO, the XML parse was written by IBM. It's a complete black box. If you don't like the way it works, you have to wait for IBM to make an enhancement, you know. So the classic example of that would be that the original IBM support didn't handle name spaces.
Jon: And so we had to wait for name space=remove or name space=merge options to be added some way down the pipe in order to avoid having to do preprocessing of XML before you could even let RPG take a look at it.
Jon: So if XML-INTO had actually been implemented as DATA-INTO and IBM had supplied us with, you know, a sample parser, then we could have made that change ourselves.
Jon: You know so it would have been literally six months―within six months of XML-INTO appearing, we'd have been able to deal with the problems, whereas we couldn't deal with them. We had to wait for IBM. And of course the other thing that I think about it that is terrific is―and you've heard me say this over and over again―is that one of the biggest problems we continue to face is that when IBM brings a new feature out, very often before Joe Average's RPG shop can use it, we're talking three months―three years down the pipe, you know, between the point in time at which IBM decide to develop it and the point in time at which the average customer can get their hands on it.
Jon: Well you know that's just crazy and the pace of dev―the way things are changing these days, you can't wait that long, you know. So if all of a sudden―you know right now JSON is the hot thing and probably will be for you know the foreseeable future, but there's nothing to say that somebody else isn't going to come up with an even lighter weight, you know, data transmission protocol than JSON. Well then we'd be waiting what, three years, before you know, IBM could do anything about it. Well as it is now it will be as long as it takes someone to write a parser and put it out there.
Paul: Yeah. I mean it's one of the things I was delighted with on this because one of my fears initially was that we were about to get JSON-INTO and―
Jon: Yes, I was―same here.
Paul: Yeah, and we remember this that the―actually I think it was within months of XML-INTO being introduced that everybody was talking about JSON, like originally whenever that was like you know―
Jon: Yes, that when it first started becoming―
Paul: It was, because that was like the early days of all the mobile stuff and suddenly JSON because in that mobile world really was coming to the fore.
Jon: Yup. Yeah.
Paul: So yeah, so have―the examples that are out there Jon, I mean, I gather they're all the standard ones for things like JSON that there is a JSON example out there?
Jon: Yeah, IBM has supplied―IBM's examples are two major categories. One is of a simple keyword value pair similar to the way that DATA-INTO and XML-INTO specify their options, you know allow missing=yes type of thing.
Jon: So there's an example parser that does that and there is also a JSON parser which is all written in RPG and they supply the code for, which it was really interesting in that the young programmer in Rochester who developed that had never seen RPG before, and―it's a nice piece of code. I mean I'm not saying that everything in there is the way I'd have done it. It's not.
Jon: But then, probably you know you and I would look at each other's code and it wouldn't be the way we'd have done it either. It doesn't mean to say we don't like the code, you know.
Paul: Sure. Yeah. Yup.
Jon: So I do intend to study that more and I want to document that a little bit better because I think there are some places where, you know, improvement might be possible, but perhaps more importantly there are lessons to be learned from coding techniques that if they're described to other people could, you know, help them out. For myself, I did in the articles that we wrote on DATA-INTO, I've done two parsers. One is a very, very simple CSV parser and the other is a slightly more sophisticated variant that uses CSVs but also uses the column headings to supply the names of the elements.
Paul: Oh, cool.
Jon: And so you know I wanted something really―you know, easy if you like―to do. I still find it very, very sad that even with the published CSV parsers that there are out there for Open Access readers and writers and now for DATA-INTO, there are still people messing around with copy to import file and all of that nastiness.
Jon: It's just so much easier if you use it directly in the code.
Paul: Yeah, true. True.
Jon: Anyway that's―I've also been playing with Jagile as well.
Jon: One of my objectives down the road a little bit is to see if I can put Jagile under the hood of DATA-INTO rather than a RPG-coded―
Jon: JSON parser.
Paul: Right. Actually funny you mentioned―just what you were saying earlier Jon about where you wait for IBM to make changes and that with it and talking of JSON, because this is something I'm in the process of actually just―when we started this, I was in the process of starting the RFE. Because one of the problems with the JSON routines in SQL, which are great and very powerful, but there's nothing there for the Boolean data type.
Jon: Oh, that's right. Yes. We've―yeah, you mentioned this the other day―
Paul: Yeah. Yeah.
Jon: When we were chatting about something.
Paul: Yeah, so.
Paul: So actually talking about chatting about things, Jon―
Jon: Yes, sir.
Paul: And because we're pretty hot off the last RPG & DB2 Summit just about three weeks ago, I think?
Paul: My God, time flies.
Jon: Yeah, that's right.
Paul: And it was our 23rd Summit.
Jon: 23rd. Yes.
Paul: Not feeling in the least bit old here.
Jon: And the third seem a day too much.
Paul: [Laughs] Okay, I should explain to people, by the way: We do run the Summit twice a year, in case they think we've been doing it for 23 years. We haven't.
Jon: Yeah, not quite that. It just feels like 23 years.
Paul: It sort of feels like 63 years, Jon, but that's beside the point. But it is funny. Just a question I was asked last week, Jon, and it would be interesting just to get your input in it. I was asked the question "why?" Why did we start doing the Summit? Sorry. Because you and I know it's not for the money. [Laughs]
Jon: No, it's definitely―no. No, this is definitely one of those ventures where you do not care what your hourly rate is because you would just go and jump off a cliff somewhere. Why do we do it? Why do we do it? I think, you know there are―the one thing that became obvious to me over a period of time is that from the IBM Technical Conference to user group conferences to COMMON for that matter, all of the conferences out there were pretty generic. They were very broad based, you know. There's a little bit of Domino, a little bit of systems operations, a little bit of RPG, a little bit of Db2, and so on and so forth. When you compared that with conferences like ZendCon, which is all PHP all day long everyday, for example―
Paul: Yes. [Laughs]
Jon: I think we just felt that there was a gap that needed filling. And eventually, because nobody else did it, we filled that gap. I think the idea that you can have basically three solid days with nothing but RPG-oriented topics or topics oriented towards an RPG developer might be a better phrase, I guess.
Jon: That if you―that if you do that, it allows people to really focus, and as we know, we do get people into change between coming to us and other conferences, you know particularly people that are in a one-man shop or a two-man shop.
Jon: They'll go to a big general-purpose conference once and then the next year they'll come to us because they just want to focus on RPG, rather than get a broad-based conference, you know. The other thing as well of course is from a size perspective. You know we always set an objective to keep the numbers relatively small so that we didn't lose the ability to interact one on one with the attendees so that all of the speakers and the exhibitors could all be part of the process and sort of create―well we work hard, as you know, to try and create a sort of family feeling about the whole things. I think that's a lot of it, just to keep that whole thing going.
Paul: Yeah. Okay. I'm so glad that you said that, because that was my answer as well to the question.
Jon: Oh good.
Paul: I didn't want to find out, Jon, that after whatever it is now―like going on 12 years―that we were all doing this for different reasons. [Laughs]
Jon: Yeah, that would have been embarrassing, wouldn't it?
Paul: Yeah. Whoops. So―
Jon: Uh no. He's gone away. I don't know if you can hear me, but I can't hear you anymore. One of the two Skype windows just disappeared. How very odd.
Paul: Oh Jon, my apologies. That was me. Can you hear me now?
Jon: Oh, okay.
Paul: Okay. Yeah, sorry. I had ac―I folded my arms and hit the mute button, I think. That was my problem [laughs]. Apologies―and just in case anybody is wondering, this is where you discover, yes, no we don't edit these iTalks.
Jon: Oh, I see. Right.
Paul: So sorry Jon. Whatwhat-what?
Jon: Good job I didn't say anything rude.
Paul: Yes. So what I was just going to say was that you and Susan [Gantner] are about to share my pain in that you are about to do the reverse trip across the Atlantic this summer.
Jon: We are indeed, yes. We're actually looking forward to it, going back to do the IUG event in the U.K. and then onto Common Europe in Poland. For me, that's a first. I've never been to Poland before, so I'm looking forward to that, and IUG, we've been there before. They're a fabulous group of people, do a terrific job of supporting the platform and it's nice to see them get even more emphasis on the technical side of things and try new stuff all the time. So yeah, should be a good show. Really looking forward to it.
Paul: Yeah, so that's in―that's in June and―
Jon: In June, yeah.
Paul: Then are you going straight from there to Poland? I mean I know Poland is the following week.
Jon: Yeah. We're pretty much going to travel on the Saturday probably and get to Poland a day or two early.
Jon: Have a chance to have a look around. Then haven't decided what we're doing after that. We may come―may go back to the UK and go visit Mum.
Paul: Yes. I shouldn't say that. I was being a bit unfair to you saying―you make the trek at least once a year across to visit family but―
Jon: Most-most-most year we try to, yeah. In recent years, anyway.
Paul: Yeah. So any vacations planned at this stage?
Jon: No, not really. We're actually in Atlanta at the moment. We came down here and we're actually going from here to look at a couple of possible future Summit locations on the way home so―
Paul: Oh, okay.
Jon: That's a big drive ahead tomorrow.
Paul: Okay well in that case I won't delay you, Jon. I will let you get your rest [laughs] because it is very important.
Jon: Yes, it is. Yes, it is.
Paul: That you check those out so I'll be talking to you before, but looking forward to seeing you in June. It will be nice to see you this side of the Atlantic again for a change.
Jon: Indeed, my friend. I'm looking forward to it and to seeing all the rest of the crew over there.
Paul: Yup. Okay, folks. That's it for this iTalk. Tune in again for the next one. Thanks Jon and bye for now, everyone.
Jon: Thanks, Paul.
Paul Tuohy has specialized in application development and training on IBM midrange systems for more than 20 years.