× 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.



Henrick,

I don't know. I haven't used any such capability with COBOL.

I'm also a PeopleSoft developer and use SQL in PeopleCode programs (a proprietary, object-oriented language). So I do have some familiarity with SQL. Just not with COBOL.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Wednesday, May 20, 2015 4:06 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

Kelly

I'm not a COBOL programmer so I have to ask if IBM I COBOL has the same inline SQL facilities that SQLRPGLE has.

To me SQL is a MUST for modern web development.

On Wed, May 20, 2015 at 10:38 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Nathan,

Hmm...this put me on a wholly different line of thought.

You're right. If we develop SPAs, then we don't need ASP.NET.

But here's my situation. Our shop currently does all web and mobile
development using ASP.NET. If we develop SPAs instead of 5250 green
screens for our IBM i users, our ASP.NET developers are going to say:
"When developing the server-side services for those SPAs, use ASP.NET
and the .NET Data Provider to perform SQL queries and stored
procedures on the IBM i. That way everybody is using the same server
side technologies and standards for our web and mobile development." And they have a good point.
It would help our shop with maintenance if everyone uses the same
technologies and standards for the server side of our web and mobile
solutions.

So why am I looking for alternatives? Because our shop tends to see
COBOL developers and ASP.NET developers as mutually exclusive developer pools.
A developer can move between pools. But a developer usually does not
do both COBOL development and ASP.NET development. So, if all of our
web and mobile development depends on ASP.NET, and developers belong
to only one pool (either COBOL or ASP.NET), then increasing demand for
web and mobile development means the number of COBOL developers will
decrease as they move to ASP.NET and those developers who stay with
COBOL will be shut out of web and mobile development. I've been trying
to find options for our COBOL developers to stay with COBOL but also get into web and mobile development.

However, it might be smarter to challenge the assumption that COBOL
developers and ASP.NET developers are mutually exclusive pools. Maybe
the right approach for our shop is to minimize the amount of ASP.NET
that our COBOL developers have to learn. We develop SPAs on the client
side using HTML, CSS, JavaScript and Angular. Then we only need to
learn enough ASP.NET to process an incoming HTTP request, use the .NET
Data Provider to perform SQL or stored procedures on the IBM i, and
format data from the IBM i into JSON for the HTTP response. This might
not be all that difficult to learn. And it might be possible to copy
code from previous apps and re-engineer it for new apps. If an
unusually difficult problem crops up, we can lean on our 100% ASP.NET developers to help us find a solution.

This didn't occur to me before because I wasn't considering SPAs before.
It was only when Buck mentioned the article on REST using Integrated
Web Services that I started thinking about SPAs with relatively thin
services on the server side. It just now occurred to me that our COBOL
developers could use a minimum amount of ASP.NET for thin services as well.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Tuesday, May 19, 2015 3:13 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service
design

On Tue, May 19, 2015 at 7:44 AM, Kelly Cookson
<KCookson@xxxxxxxxxxxx>
wrote:
Why not just learn .NET web and mobile development and keep
everybody on
the same standards?

Given your preference for single page applications (SPAs) and
retaining "state" on clients, it seem to me that the only reason for
ASP.NET would be when clients need to access resources on Microsoft servers.

Wouldn't ASP.Net be completely superfluous, for clients that need to
access IBM i resources? No need for ASP.Net to dynamically generate
HTML because HTML would be static. No need for ASP.Net to maintain
sessions, because clients maintain their own state. No need for
ASP.Net to provide a gateway to IBM i data and other resources because
those resources could be accessed via an IBM i HTTP server and an IBM i Web Services Utility.

In the case of IBM i resources, it appears to me that ASP.Net would
just add latency, add a potential failure point, add complexity, add
needless security requirements, be a potential bottleneck, add cost,
and be completely unnecessary. It could save time, save money, improve
security, and improve the user experience by eliminating ASP.Net from the mix.

This perspective assumes that you have real intent to develop SPAs
which maintain client state, and control the interactions between the
client and an IBM i HTTP server. The HTTP server and an IBM i Web
Services Utility could be the gateway to IBM i resources.

Although the client's interactions with a Web Services Utility might
be via simple URI and an exchange of JSON objects, you might
streamline the interface via a JavaScript API which might be paired
with the functionality of the Web Services Utility.

var tableName = 'STUDENTS';

statusObject = wsuStatusObject();
studentRecord = wsuGetRecordObject(tableName);

studentRecord.lastName = form[0].lastName.value;
studentRecord.firstName = form[0].firstName.value;
studentRecord.middleName = form[0].middleName.value;
studentRecord.gradeLevel = form[0].gradeLevel.value;

wsuWriteRecord(studentRecord, statusObject);

if (statusObject.error) {
...
}
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.