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