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



Kelly,

This statement interested me:
"This has been due to .NET having it's foot in the door, thanks to our
corporate web site, and no one knowing how to develop web and mobile apps
using IBM i technologies."

This (mainly that latter half of the statement) makes me think that
application developers these days rely too much on "middleware".

If anyone understood what makes a web application "mobile", "responsive",
etc they'd realize in the end it's just HTML/JS/CSS. And with all the
frameworks available today there's no reason to pick one over another.

In fact, when I was playing with bootstrap a while back I thought.. hey
this is ok. And then I realized why most blog sites look the same (to
varying degrees) today and decided to handle my own CSS for the most part.
:)

The biggest issue isn't what we "call" the IBM i... it's the perception of
what it can do.

When we here .net we think web apps.
When we here IBM i we think green screen.

That's the problem. :)

Brad
www.bvstools.com

On Sun, Oct 4, 2015 at 8:05 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx> wrote:

Hi Henrik,

One thing I would have expected to find in a logistic and redistribution
company was a strong emphasize on EDI communication...

We have a team devoted exclusively to EDI. Our team has been involved in
some industry leading projects in foodservice distribution:
https://www.dotfoods.com/who-we-serve/your-resources/ecommerce/suppliers/
Although one of the 3rd party vendor packages used by the EDI team runs on
the IBM i, our EDI team has no IBM i COBOL developers. They don't do IBM i
development.

What I also am missing in your description is what the current status
is and what the goal of the technical exercise is e.g. run your web
technologies primarily on .NET with IBM I as a backend delivering raw
data or let the IBM I have a more active role in the overall web
application
delivering runnable components to the overall web application.

You're missing this because this is precisely the question I want to raise
in my company. Right now, when it comes to web and mobile apps, we're only
using the IBM i as a database at the very back end of web and mobile apps
(a backend delivering raw data to borrow your words). But this has been a
deliberate decision. This has been due to .NET having it's foot in the
door, thanks to our corporate web site, and no one knowing how to develop
web and mobile apps using IBM i technologies.

I want to raise the question of where this positions our IBM i servers in
a world of web and mobile. Do we really want to position our IBM i servers
as nothing more than databases at the very back end of web and mobile apps
that otherwise run on Windows? Or do we want to develop web and mobile apps
that are hosted by the IBM i (i.e., that use programming languages native
to the IBM i and web servers on the IBM i)?

And, hence, the motivation for this post: What if our shop decides to
deliberately position our IBM i servers as databases at the very back ends
of web and mobile apps? Should our IBM i COBOL developers be doing things
differently? For example, should they become data-centric developers? What
can they do to best leverage the IBM i as a database sitting at the very
back end of web and mobile apps?

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx


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.