On Thu, Mar 19, 2015 at 10:24 AM, <rob@xxxxxxxxx> wrote:
Sorry, this is going to come off harsh. I really mean it with love
though.
I don't think it's overly harsh. It's not warm and fuzzy, but I think it's fair.
God save me from people that are so API phobic that believe every solution
is to generate a spool file, copy it to disk, and analyze that!
Really, parsing out a substring that can shift positions in the line based
on how long the job name and/or user are, or what version of the OS you
are running, or... is easier than learning something new?
I can't speak for all non-API users, but I will say this for myself:
As someone who is comfortable with and reasonably well versed in
parsing text, the answer is a resounding "yes!": it really is VASTLY
easier and quicker (and, believe it or not, in some cases MORE
reliable) to parse spooled output than to rely on IBM APIs.
I think it's worth giving context, too. I'm a Windows and Unix
programmer at heart. Streams are bread and butter for us. Actually,
what we REALLY love are... APIs! But to us, CL commands *are* APIs.
The amount of convolution required for IBM system APIs is... OK, I get
it, I truly do, that once you're used to them, and if you have the
right tools (like RDi with nice plug-ins and whatnot), it's not a big
deal. Especially since once you've set something up once, you get to
reuse it and next time it truly is no trouble at all, any way you
slice it.
Believe me, I get it.
But watch someone who is good at Perl and Unix scripting do their
thing. It is stunning how much easier and quicker it is to parse text
than to set up all the rigamarole of an IBM system API. It is so easy
for an accomplished Perler that there is no need to write a program;
just enter it in at the command line. And, if it starts to get a
little too complicated to remember or to enter repeatedly by hand,
then sure, just copy what had been entered ad-hoc, paste it into a
(stream) file, and boom, there's your reusable utility program.
I will also say this: CL string handling is crap. Maybe a little less
crappy with the latest RPG-inspired additions. But even RPG is not
great. It's certainly no Perl.
Folks like me (and certainly folks much better than me) are not
putting fixed column positions into our text parsers. So our parsers
are really not that sensitive to changes. We use programming languages
that have dynamically sized collections built in, so we're not futzing
with pointers.
But speaking of dynamically sized collections, SQL has those! You have
been mentioning the SQL-based resources a lot lately, and I think THAT
is the way to go. In effect, as long as what you are looking for can
be found in tables/views, then you can use SQL as your super-easy
scripting language, and worry about neither parsing text nor "parsing"
data structures.
So yeah, keep pushing SQL. I'm 100% behind that.
I have to admit I haven't explored the SQL-able resources all that
much. But already I'm surprised and impressed by how much is available
there.
John Y.
midrange.com
