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


  • Subject: RE: alternative to WebFacing
  • From: "jt" <jt@xxxxxx>
  • Date: Fri, 22 Jun 2001 12:30:42 -0400
  • Importance: Normal

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Stone, Brad V (TC)
Sent: Friday, June 22, 2001 8:12 AM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: alternative to WebFacing


e-RPG works pretty good!  Thousands of readers can't be wrong.  ;)

Brad

> -----Original Message-----
> From: Jim Franz [mailto:franz400@triad.rr.com]
> Sent: Friday, June 22, 2001 6:38 AM
> To: MIDRANGE-L@midrange.com; IGNITE400 MEMBERS LIST
> Subject: alternative to WebFacing
>
>
> is there an alternative to IBMs WebFacing for a system too
> small to run WebSphere? Prefer without the run-time license
> of like Seagull. Something reliable?
> jim
>

=======================================================


Jim/Brad/All,

As you know, Brad, I'm one of those thousands of readers.  I agree with you
in part.  An alternative to WebFacing could be written.  This is what I know
of it so far.  Most of it is theoretical, so many will say it's a bunch of
hooey.  For the technical folks, I'm doing this from memory and don't have
time to look in the books, or the little code I've written.



I read Jon Paris was doing some write-up on how to use SPECIAL files, but I
haven't read it.  SPECIAL files are the way to go.  With a simple conversion
program, you change the F-spec, and change all your EXFMT statements to
WRITEs and READs.  You use the QDBRTVDB to add the I-specs and O-specs
pretty much the same way the RPG compiler adds them.  I did a pre-compiler
that did precisely this on RPGII programs, before I started working on a
S/38, so this is easily doable.

(Although one non-trivial detail is the I/O feedback area.)

Using SPECIAL files you then have to supply a common I/O module.  This
program (more likely *SRVPGM) needs to do the open, I/O and close.  This
*SRVPGM gets the data structure you set up in the I/O specs.  You can add
additional fields that the *SRVPGM needs;  you just have to define and set
them up with the pre-compiler.

You've just separated your presentation from the business logic.  Easy, take
just a few seconds per program.



Communications is not a done deal, but I've done enough playing around to
think this part won't be as bad as I'd first thought.  I'm not saying that
setting up multiple sockets queues is necessarily a snap, because I haven't
done it.  Some of this is guesswork, if you want to call it that.  The
sample is in the Sorcerer's Redbook, so I just don't think it will be that
bad.  I can say I've sent info back and forth using both CA data queues, and
sockets.



For the presentation, I agree the e-Rpg may be the way to go, but I'm don't
have enough experience to talk about how to do that.  I'll talk about this
in terms of a client/server environment.  Nothings to say you couldn't do
this in either, or better yet both, ways.  Should be able to pretty much
just by passing a flag.

I've toyed with VB since VB 1.0, but I'm still a clod with it.  But I have
written a real crude proof-of-concept where the 400 sends down some DDS and
the PC displays a screen consisting of all output fields.  Obviously you
would want to use the QDBRTVDF (?) as was mentioned on a reply to a previous
post Joe Pluta wrote.  Not having done input fields, it's pretty hard to
even call this a proof-of-concept.  But 10 years ago I wrote a program in
DOS Basic that handled input and output using a table of fields that were
more-or-less like DDS.  So I believe a client is doable.  I've seen Nathan
Andelin's posts, but to be honest, I've been meaning to look at his demo but
haven't.  I don't need to look at it to know he's way beyond this.
As far as e-Rpg, I hate to speak in front of the master.  But yeah this can
be done.  The hang-up I've always had with this approach is the user
interface.  Which is a lot harder to control than with a VB client on a PC.
There's been some discussion on IGNITe, I think, about using a mouse vs.
keyboard.  I'm go to go out on a limb and say that the worst possible
interface is one that requires both.  People say "get used to the browser
interface, you don't need command keys".  I'll go along with that to a
point.  But a mouse is horrible for heads-down keying.  How can you overlook
that?  And switching between mouse and keyboard for heads-down keying...!

IMHO, if you develop a user interface like that you're doing the exact same
thing as the developers of the InfoCenter.  Delivering a product that is
pretty, but extremely dysfunctional.  AND FORCING PEOPLE INTO IT.

So I've been looking at DHTML.  I know you can control cursor movement, the
keyboard, have capability to position output to absolute locations on the
screen, etc, etc.  Given that M$ and Netscape have differing standards.
That's a tough one.  Do you wait until HTML 4 (I don't even know where it's
at?) or do you settle for the least common denominator, or do you settle for
the one that has (essentially) the monopoly?

I've only looked at IE DHTML (briefly).  I did see something they refered to
as HTA (HTML Applications).  It appears to be a way to use the browser as a
custom client.  The screen shot I looked at looked just like a PC client, no
Explorer toolbars or anything like that.

Knowing Brad's on this list (though he may skip by my posts) I know I'm in
the presence of the guy that literally wrote the book.  So who am I to talk
about these things.

And, given the bank of experts on this list, I hesitate to write anything at
all.  I've done a lot of this just once, to see if it could be coded.  So I
know my expertise pails compared to most all of you technical folks.

But I've seen reams on this topic of how to code C/S/Web interfaces.  I
haven't seen this particular approach mentioned.



BTW, sure you could hook into the SEPT.  Saw some talk on MI-L but didn't
follow it too close.  I couldn't do something like this but a friend and
former partner wrote the first (AFAIK) non-IBM MI compiler in 1983.  There
was no API or manuals, he did it with the Func Ref and the PCHPGM.  He could
probably hook the SEPT.  But why bother complicating things?



This is another post that might not make much sense, I don't know.  If your
not technical, probably not.  If you're technical, maybe not anyway...:)

If you're technical, then you're probably thinking there aren't enough
details laid out here, or you're seeing areas that you don't think are going
to work (or maybe you're thinking you already have a better way of doing
these same things).  I've always found there are adequate solutions to
technical problems, and these thoughts here are obviously just a quick
overview.



I think this could be a direct application and one of the biggest benefits
of the iNation.  What would it take to eliminate the interactive penalty?  I
think it would require:

that people quit wasting time complaining about it
some brains volunteered to work out the details
someone to lead the charge
some computer time
some way of providing long-term support

I don't know if anyone is even reading this far down.  But depending who is,
some people would say the technical details are insurmountable, and some
would say you could never get heavy-hitters who could code this kind of
stuff to work together.

Maybe so.  I'd say the main problem is it's easier to complain about it, and
very few companies would take a chance on system software like this, unless
they thought they could get support if there was a problem.  What are they
going to do, if all of a sudden all their interactive applications wouldn't
function?

That's a show-stopper.  That's why you'd want to do this under the iNation
flag, so to speak.

Clearly the value is two-fold:  companies that have a 400 would sure look at
it different if they could get a lot bigger bang for the buck.  Maybe the
main benefit would be the Citizens trying to collaborate.


So maybe this is a little long-winded (a little !?! :-) way of saying, yes,
I believe you could use your existing 400 to do these things.  And better
yet, you could use SDA to put out screens to run on the web and PCs.  Talk
is cheap, it would take some people to do this...  Why wasn't WebFacing done
this way?  Don't know for sure, but IMHO it's because they're located in
Toronto instead of Rochester...  Don't know anyone up there, but traded
e-mails with Barbara Morris once.  She was real nice so I'm sorry, but
that's MHO.


I'm not a big fan of OSS, and I think one of the first (if not the first)
things I wrote was to counter Leslie Russell's article in News/400.  IMHO,
one indication the FSF/OSI is not a good model is that they don't concern
themselves with issues like support.  They figure it'll just happen.  And it
doesn't.  And it seems like they're always looking for grunts to do the
documentation and testing while the stars getting to work on the parts of
the code they feel like working on that day.

But I still remember Nathan Andelin's response on the different reasons
people might want to try to do something like OSS.  They were good reasons.
IIRC they're the same reasons why people might want to try out the iNation.
The question I had at the time (can't remember if I wrote this or not) is
that it takes so much hard work, and perseverance, to do these things right.



I, personally, would be willing to help on an OSS project like this one, but
I'm just an old green-screen dog.

But I'd try ***if it appears it might be completed and bring some
benefits.***  I can't see the sense of trying to do this unless the iNation
is behind it, because if IBM is against it, nothing good will come of it.  I
wouldn't have time to waste on something, if there was absolutely *_no_*
chance that something good could come of it.

Plus, there seems to be a blanket assumption that ending the interactive
penalty would be a great thing.  It _would be_, for people wanting to buy a
new 400.  But anyone who owns a 400 with the interactive feature (just about
everyone on this list) would see most of their resale value wiped out.  And
what would it do to businesses that re-sell 400's?  Those are other reasons
I wouldn't do anything, personally, unless it was backed by the iNation.
Nothing to stop someone else from doing it; but I would wish them nothing
but bad luck on the project.

I don't know if Neil or Don can, or would want to, help out in this regard,
should others have an interest in pursuing it.  Maybe they could see if the
iNation would back some OSS development like this one, or something else.
Maybe they could fulfill the charter about "serving the needs of the
Citizens".

Anyhoo...  I'M LATE, gotta run.  Have a good one!

jt




BTW: I wrote Mr. Haines recently, that I wouldn't work on this, because I
knew that might cripple iSeries profits.  (How long would the iSeries
survive without profits?  I wouldn't want to take a chance.)  But I figure
Joe Pluta or someone else is going to be doing this anyway, eventually.  Why
not the iNation Citizens?  And if Mr. Haines or IBM really doesn't want the
iNation to support this thing, they don't have to.

I believe that some Citizens will stop telling IBM what to do, and they'll
just go out and do the things that need done.  Like Nike says...  Like go
out and do some marketing above and beyond what IBM does.  Do it better than
IBM does.  The iNation will have opportunities IBM could never have...  And
if that happens, I think increased sales will offset loss of gross margin,
so that's why I'm going back on what I wrote Mr. Haines.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.