× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Although I *don't* use DSM for displays (i have but anyway...ick) it's not
that i don't understand your point. it's just that i don't agree with
*all* of it. and yes i meant permanent log and i do that at the database
level as well...however i'd prefer to know enough that i can interrogate
the actual data being sent and *how* it looks during the transport phase.
being able to see that i sent the data is one thing. being able to ensure
that the format of the data (i.e. the XML) is correct, i'd like to be able
to look at it and *know* i'm sending the data as it is expected to be on
the other end. i know i don't *have* to write the code to support JSON,
XML,etc. but being able to interpret the output visually is a *good*
thing.

Thanks,
Tommy Holden



From:
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
To:
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
Date:
04/28/2008 09:39 AM
Subject:
Re: [WDSCI-L] "EGL is the easiest langauge to learn" - Joe Pluta was->
Problem updating Rational Developer for System i for SOA Construction



Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:
Sorry if i missed this somewhere but....

And I'm going to be careful in my responses, because it's clear you're
offering your opinion, and I don't want to get into opinion wars.
Joe says "RPG programmers don't need to learn about XML or anything
else.
They simply define the parameters in their function and EGL does the
rest.
"

i beg to differ (i know i took this out of context however...) IMO any
RPGer that DOESN'T learn at least *some* XML is gonna be lost using
*any*
of these processes.
Well, you can learn XML or you can learn JSON, which is the other
standard, especially for tightly coupled systems. Bit in either case,
you don't need to write code to support either; you should use library
functions. EGL has support for all these functions, and RPG has support
for XML, either natively through the language or through third-party
products like Aaron's.

since the input/output data is in XML it's only
natural that you would want to be able to translate data being passed
*regardless* of it's format.
I'm not sure I understand this, Tommy - are you talking about something
like a communications trace for debugging purposes, or are you talking
more like a permanent log? For the latter, I do that at the database
layer. But I agree that it would be good to have some sort of logging
at the service level of the traffic.

i haven't used EGL personally but here's my
limited take on this. i simply *abhor* code generators of any type! (no

offense to those who do...you're braver than i am!)
Yeah, 20 years ago I would have had the same sentiment. But then again,
20 years ago I could do everything in an ERP shop with one machine (the
System/38) and bisync communications to the mainframe. Now, some shops
have the luxury of learning every new technology and every new
communications protocol, but most people I know don't want to have to
worry about XML namespaces or WSDL configuration; they want to
concentrate on the business logic.

In fact, that's what the projcet I'm working on is showing me. I'm
going to write three new services this morning. With EGL, I don't have
to worry about formatting data or anything like that. I'll write a few
lines of EGL in a function that accepts some data, calls an RPG program,
and returns the result. I'll generate the WSDL, send it over to the
client, and he'll program the interface. Done deal.

So I guess my point is that I don't mind using a code generator for the
kind of code that ought to be generated: namely, the plumbing between
the pieces. I've written dozens of client/server interfaces over the
years, and I don't really want to write anymore. If EGL can do all that
for me, then I'm happy to have the help, so I can concentrate on the
business logic.

but i *will* echo
Aaron's statement, RPG *should* have native GUI capabilities *without*
all
the extra gyrations, wrappers, etc.
This is the classic example of "It's not gonna happen, so why waste
cycles on it?" The more time people spend arguing on a native GUI for
the 5250, the less time we spend on implementing real solutions.

Anyway sorry for the long diatribe but in short my opinion remains that
any and all programmers RPG or other *should* at least have a
rudimentary
understanding of transporting data via XML or any other standard that
becomes a viable, useful means of data transfer method.

Hey, no problem.

One question, though. You say you hate code generators and you think
everyone should understand the transport layer. Okay - you do realize,
though, that display files are in effect code generators, right? How
well do you actually understand the 5250 data stream? Do you use the
DSM APIs, or do you use display files?

It's a bit of a stretch, but I hope you see my point. You're willing to
use the workstation gateway software and the RPG compiler to make your
life a little easier because you don't really need to know the actual
hex codes involved with the 5250 data stream. I'm willing to let EGL do
the XML and JSON plumbing for me, because I really don't need to know
that part.

Joe

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.