Re: Why use PHP? What are the disadvantages? -- WEB400

Regarding the idea of RPGOA being a screen scraper, I can see the point, to a degree. The file on the "F" spec may be a *DSPF, and the device type may be WORKSTN. But it's also meaningful to note that new handlers take control BEFORE, and INSTEAD of the traditional routines that generate and serialize a 5250 data stream. The interface is also much more flexible and modifiable in that handlers can define additional data structures to be passed, in conjunction with normal data buffers. That opens new functional possibilities that were unavailable to traditional screen scrapers.

I like the design of the interface. I like the idea of having a consistent and familiar interface to communicate with contemporary devices in addition to traditional devices. My biggest concern is that IBM's packaging it as a new product with a separate price seems rather contrived. Third party vendors may say to customers, well you can evoke our open(), close(), read(), and write() procedures directly, or if you want to use the traditional open, close, read, and write op codes, you can license that capability from IBM. But the functionality is the same. So what is the sense of licensing an additional interface from IBM?

Open, Close, Read, Write op codes are already inherent in the RPG compiler. Why make them a separate products, now? Is this a precedent for charging separately and individually for new op codes and %bif()? If so, a number of programmers will just create and evoke procedures directly, rather than using op codes and %bifs() in the compiler.

-Nathan.

----- Original Message ----
From: "BButterworth@xxxxxxxxxxxxxx" <BButterworth@xxxxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx
Sent: Wed, April 21, 2010 8:37:29 AM
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?

I think Scott may have been being a little sarcastic when he said RPGOA is
a "screen scraper" technology, but I will let him speak for himself. You
are still generating a web UI via the medium of RPG I/O and opcodes, which
seems less intuitive to me. I haven't seen your product or Profound
Logic's product and don't mean to belittle them. If they can be used to
re-configure existing (monolithic) heritage applications with little or no
effort, then I do see an advantage there for companies who have neither
the time or resources to re-write their applications. As regards new
development, however, it still seems to me we could already do everything
(including session management and security) using system APIs, service
programs and procedures before RPGOA. I was using Valence merely as an
example. I'm not familiar with all the third party tools that are
available for RPG development.

My point about WYSIWYG tools and Javascript is that regardless of RPGOA, a
RPG developer is going to have to learn one, the other or both to do web
development. RPGOA and associated third-party tools are not going to
provide a silver bullet such that developers can develop web UIs/apps in
the same manner as green screen apps and get a decent web 2.0 UI. If a
developer wants to use WYSIWYG tools, code-generators, etc., that's fine,
but then one becomes limited to/by the tool vs. doing the actual coding.
So it seems to me some forethought has to be given to how established the
tool is, what kind of backing it has in the community, etc. before a long
term investment is made. The same is true for language frameworks, but the
popular ones generally have a much larger developer base (e.g., Zend,
Dojo, JSF, .NET, etc.) and provide more resources for trouble-shooting and
research.

Blake

I think you're wrong on a couple counts. First, RPG OA is not a screen
scraper, it completely changes the datastream so that the handler can
deliver an appropriate persistent connection. You can write new code
without changing the interactive development paradigm. For developers who
find persistence and host (server) side control to be an advantage, then
it
is a game changer for the platform. Secondly, Valence has come up with
nothing new. The looksoftware smartclient has supported new forms with no
associated host screen, RPC, database access, and web service consumption
since R7.0, which was delivered in 2005. Certainly extending one's skills
is important, but learning a WYSISYG design tool is really not painful,
nor
is vbscript or jscript for that matter. Take out the pain of middleware
development and you've got a great new opportunity. The application
portfolio of the IBMi is so replete with heritage code that is not viable
for replacement that RPG OA will likely add another decade of life to many
applications. Viva la RPG.

Pete Isaksson
petei@xxxxxxxxxxxxxxxx
Business Development Mgr
www.looksoftware.com
+1 678 494-5465 office
+1 678 662-2400 cell