But how much of the IBM i world has embraced and built core business functionality into SubProcedures ?
More than have embraced stored procedures?
Uh, OK. Good answer :-)
Helps define it better.
It is just one more tool in the box.
On that we are in agreement.
Your tooling and general experience is exposing IBM i to .Net - it is inevitable that stored procedures are at the forefront because your need is to retrieve via SQL. My main exposure is in helping folks to make the best of what they've got. And what they've got is programs and subprocedures. If they want to expose them via stored procedures then they have to learn that layer. One of the aspects of XMLSERVICE that is interesting is that the IBM i crowd don't actually have to do any work - they can just hand over the program name/library plus parameter definitions to the other side and let them build the XML etc. You'd be surprised how attractive that is for a lot of folks.
Not sure how much you know about my general experience or tooling. We've never talked in-depth and you've never seen my tooling :-)
I also help development teams determine where their skillsets are best utilized and introduce new technologies where appropriate to modernize.
I do like the XMLSERVICE concept and will probably even use it, but it's really about appropriate division of labor. Do you want the iSeries developer or the .Net/PHP/Java developer to do more re-work/programming for application Interop ?
The answer is: It Depends on lots of things most importantly availability of qualified staff on the Windows, Linux or i platform.
Personally I use SQL, remote command, program calls, stored procedures, data queues, direct record access and data area access as well as IFS file transfer to accomplish application interop depending on the circumstance and what the development team is familiar with.
That could lean me towards XMLSERVICE in some cases, ODBC/OLEDB/ADO.Net in others, JT400 in still others and simple CGI-rest in other cases. Still haven't fully bought into RPG-OA as an appropriate modernization technique although I know it's been ideal for others :-)
In your case I think you generally lean towards RPG/PHP (at least from all the articles I've read) which is OK, but don't presume that some of the other modernization technologies might not be better suited for modernization efforts.
You could always take a little .Net class for a full rounded perspective.
Visual Studio Express is FREE and 2012 is just around the corner. Oh, and you can run it on the MAC ala VMware :-)
In either case we're fighting for the same cause: Keeping IBM i in place in our customer accounts.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
----------------------------------------------------------------------
message: 1
date: Sun, 12 Aug 2012 15:55:35 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [WEB400] XMLSERVICE with .Net
On 2012-08-12, at 1:00 PM, web400-request@xxxxxxxxxxxx wrote:
But how much of the IBM i world has embraced and built core business functionality into SubProcedures ?
More than have embraced stored procedures?
It is just one more tool in the box.
Your tooling and general experience is exposing IBM i to .Net - it is inevitable that stored procedures are at the forefront because your need is to retrieve via SQL. My main exposure is in helping folks to make the best of what they've got. And what they've got is programs and subprocedures. If they want to expose them via stored procedures then they have to learn that layer. One of the aspects of XMLSERVICE that is interesting is that the IBM i crowd don't actually have to do any work - they can just hand over the program name/library plus parameter definitions to the other side and let them build the XML etc. You'd be surprised how attractive that is for a lot of folks.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
midrange.com
