Unconfigured Ad Widget

**H.Boldt** · 08-21-2006, 08:28 AM

Retrieve the Function Key Used on a Display File

Ralph wrote: "... simply because IBM refuses to provide a native GUI interface for our RPG interactive sessions." I've seen a number of people request a "native GUI interface" for RPG. Please forgive my stupidity, but what exactly is being requested? Isn't there already a native GUI interface in the form of HTML and CGI? Or do some people want some sort of proprietary, RPG-specific interface definition language? Cheers! Hans

**WoofDog** · 08-21-2006, 09:40 AM

Retrieve the Function Key Used on a Display File

I for my part would like IBM (or some IBM-endorsed open standards body) to define a new telnet standard that would allow me to place and show graphic elements on the screen, place fields on the screen, not based on crude line/character positions, but based on a x,y position specified as pixels or a (perceived) fraction an inch/a cm - in other words, much like a AFP (or Postscript?) data stream for the screen. I also want a much larger number of colors to choose from. Plus many more things... :-) If they want to make the data stream XML based, why not? As long as we as programmers don't have to be directly involved or knowledgeable about it. It would of course be nice if we were allowed to send some kind of scripting code for the client along as well (like JavaScript for the browser). But please don't tell me that web technology is the answer, because it's not. Let me maintain the direct control over the workstation, not drop the connection between every single entry. Http-based webserver/browser communication just isn't good enough for anything but casual browsing. And never will be...

**David Abramowitz** · 08-21-2006, 03:45 PM

Retrieve the Function Key Used on a Display File

There was much left to do and improve on the existing 5250 data stream when IBM decided to freeze it. Little things like more colors, additional fonts, and mixed fonts fall into the existing 5250 capability, but are unabtainzble without using APIs. A quarter century ago, IBM did start a 5250 GUI, that (at the time) was on an equal basis, or ahead of the competition. It is most unfortunate that GDDM was, in essence, abandoned. Any current criticism of GDDM is out of place as there is a quarter century of catch-up needed. The point I am making by bringing up GDDM, is that it can be done! Dave

**J.Pluta** · 08-21-2006, 08:50 PM

Retrieve the Function Key Used on a Display File

There are a few folks who consistently talk about some sort of RPG-centric UI language, Hans, but they miss the point entirely. RPG should be a business logic language with a front end of your choosing for building the UI. Now, if you don't have anything better, you can use RPG-CGI, but a thin JSP layer is better (in my book), and if you don't want to code Java, EGL is even easier still. I'm not sure what's on the drawing board today for an EX-UI opcode, but I'd just as soon leave the old panel/subfile/popup paradigm behind and move on to a more interactive UI based on HTML and JavaScript (with maybe a little AJAX thrown in). Joe

**R.Daugherty** · 08-21-2006, 10:49 PM

Retrieve the Function Key Used on a Display File

Hans wrote: Isn't there already a native GUI interface in the form of HTML and CGI? For starters, CGI is not a 5250 interactive session. CGI programs were created to process web pages. They get loaded and initialized with each incoming page, from any user at any time. For that reason they would necessarily be small and oriented around processing an atomic page size transaction, from the data on the web page, and then issuing the appropriate next web page. This is ideal for what web pages were invented for, to browse anonymously, randomly, in any order, from anything at any time. That is the opposite of business transaction processing, for which 5250 and 3270 session protocols are used. To accomplish this with CGI is to first emulate 5250 sessions between web pages with every variable, every aspect of a program, every file pointer position restored from whence the last screen was sent to that user by some CGI program, long gone. So an infrastructure to save and restore the entire program environment is required to do this or else the CGI programs could only do what they were designed to do, act unknowingly on each new web page coming in, blissfully retrieving whatever data was requested. Fine for anonymous browsing, worthless for business processing. And what has IBM staked their very existence on? Websphere, a web page infrastructure. So of course IBM offers CGI and HTML for a native GUI. To use it requires the equivalent of Websphere, something they really care about versus, say, OS/400, which they advertise as good for backing up Windows and Linux disk drives. Now who else pretends that web pages are a native GUI for their OS? No one. Motif, Gnome, KDE, Windows, Mac, all are GUI interfaces and none are web pages. That is what other OS'es have. No one else says program with CGI and use HTML as your UI. Only IBM because it has bet the farm on Websphere and is desperate to force anyone they can control, say those of us left on OS/400, to use it or go down with them, or don't use it and go down with them, whatever, but it won't be because they treat OS/400 as an operating system that runs billion dollar corporations. Who else uses web pages as a UI? Oracle. Why? Because like IBM, Oracle sells middleware. They don't really care so much about the UI as selling their database middleware. User interfaces are more of an inconvenience to people like IBM and Oracle. Lowest common denominator, OS independent, who cares about people that actually use the business applications developed with that stuff. It's all about IBM and Oracle and their middleware. But SAP doesn't sell OS middleware, they sell business applications. And did they develop their business software with web pages and CGI? No, their future interface is Flash. And they're integrating with Microsoft desktop. Those are the things I called for for the AS/400 six years ago. Companies with vision went that route. IBM didn't. Flash is a desktop independent GUI user interface, but it's desktop. So is Gnome GTK. So is IBM's Java Eclipse RCP. Eclipse makes the most sense from IBM's point of view. SAP has probably made the smartest choice with Flash. Gnome GTK is probably the most powerful. But if IBM implemented a native GUI interface with a 5250 buffer API as I suggest, Eclipse could be the native UI but all of those desktop UI's could be supported. The key is a desktop GUI user interface to an OS/400 interactive session. The difference is an interface to an EXFMT buffer, not a CGI program. rd

**Guest.Visitor** · 08-22-2006, 05:27 AM

Retrieve the Function Key Used on a Display File

It was easy on 360 when the data was punched on cards and we simply processed data and produced reports. Then came in terminals and the buzz word "Online Processing" and we got confused about our roles. It was a matter of prestiege. We, the "batch programmers" of mainframes 36x using COBOL, were looked down as obsoletes and dinosaurs by "Online Programmers" of 3x using RPG. Well some of us made the transition to subfiles and took control of front end as well. I was good to feel "not obsolete". Now, we the "Green Screen Programmers" of S3x/400 using RPG, are looked down as obsolete and dinosaurs by "GUI Programmers" of PC using .NET. Unfortunately this time over we do not have a clarity as to how to regain the control of front end and remain "not obsolete" for a few more years. Probably last time we were competing within IBM and this time it is MS and other BS.

**H.Boldt** · 08-22-2006, 06:09 AM

Retrieve the Function Key Used on a Display File

Joe wrote: "There are a few folks who consistently talk about some sort of RPG-centric UI language, Hans, but they miss the point entirely." Exactly. Ralph: To get to some of your specific points: "... every file pointer position restored from whence the last screen was sent to that user by some CGI program, long gone.... " Generally, it's not a good idea to maintain locks across transactions. That is, if someone is in the middle of a transaction, has a bunch of records locked, then takes a long lunch break, others may be locked out. Yes, CGI has a different way of dealing with transactions, which means a different way of programming. But transaction state is easy to save in the database, and easy to recover when the same end-user comes back into the application. "Motif, Gnome, KDE, Windows, Mac, all are GUI interfaces and none are web pages." Do you know what's involved with programming these GUI's? For any of them, the manuals are at least double the size of the RPG manuals. And for every one of them, they still involve a change in programming style of some sort. That is, they are generally event driven, possibly at a very low level of interaction with the API, not record driven. Furthermore, the GUI's you mention are all programmed using an API. That is, there is no language specific aspect to them. Theoretically, all you would need is the API ported to the i5/OS, and you would be able to use it immediately from RPG. Which gets us back to Joe's point: RPG is good for the business logic. Other tools are available today, and better suited to the user interface than is RPG. The impression I get is that some RPG programmers want to continue to work using a 5250 style of programming, even when adding a fancy GUI to their applications. My point is that, whatever form of GUI you want (CGI/HTML or some complex event driven widget API), you have to change the way you look at programming. Enhancements to RPG aren't necessary. Nor would they even make things any easier for you anyways. (Or you could just use some transitionary tool like WebFacing.) Cheers! Hans

**H.Boldt** · 08-22-2006, 06:26 AM

Retrieve the Function Key Used on a Display File

Hassan wrote: "Unfortunately this time over we do not have a clarity as to how to regain the control of front end and remain "not obsolete" for a few more years." That's the issue in a nutshell, isn't it? It's a problem all of us in IT face throughout our career. Without continuing eduation, we all face the prospect of obsolescence. The past decade has seen a massive paradigm shift in computing, and those you won't, or can't, adjust will be left behind. In a free market system, that is the harsh reality. And unfortunately, it's a reality that some in the Series i community have difficulty in accepting. Cheers! Hans

**Guest.Visitor** · 08-22-2006, 08:26 AM

Retrieve the Function Key Used on a Display File

As you quoted, the problem is of clarity this time. Probably because we were competing within IBM last time and we knew what needs to be learned to remain "not obsolete". This time the hell is let loose on us to decide. Go for "Web's fear", "MS BS", go BI's BW's BS'S, or just forget everything and jump on to SAP. Most of the 18 people laid off last week are heading for SAP as the chances are that this "Walmart" will kill most of development jobs.

**Steve.Kiferd** · 08-22-2006, 08:48 AM

Retrieve the Function Key Used on a Display File

I think if you learn .NET or Java, HTML and JavaScript then add related technology on top of that you would be okay. The issue I have as a consultant is the opportunity to not only learn these new technologies but put them to use. Most clients today want a specific skill set with a high degree of experience coming in the door. On top of that it seems most iSeries clients are still mired back in the 80's. The only client opportunities I get are for more 5250 development and you have to wonder how long that will last. Making this transition is worse then trying to get a chance to move from the S36 to AS400 over 15 years ago. Some of the ideas presented in the book Who Moved My Cheese come to mind. But I think the cheese left the country a long time ago.

**Guest.Visitor** · 08-22-2006, 08:58 AM

Retrieve the Function Key Used on a Display File

Hi Ralph, Ralph wrote: CGI programs were created to process web pages. They get loaded and initialized with each incoming page, from any user at any time. Huh? This is not absolute - it depends. If you exit the CGI (RPG programs) with *INLR=*OFF (why wouldn't you? or have it exit with *INLR=*ON after every 50 calls, etc), the program remains in memory for that server job, waiting for the CGI traffic cop to route the next connection to it. These server jobs are shared amongst all CGI users. Servlets/JSP work well too, since they get loaded once and remain in memory. Ralph wrote: This is ideal for what web pages were invented for, to browse anonymously, randomly, in any order, from anything at any time. That is the opposite of business transaction processing, for which 5250 and 3270 session protocols are used. So, how do you explain the success of web based transactional applications? You know, Dell, Amazon, Best Buy, E-bay, etc. Have you ever bought anything via the web? Are they operating in a house of cards, ready to blow over? Or have they proven that the web UI works? A servlet can keep track of the "current" page in the session object or use the Post-Redirect-Get technique so any web page contains current state. Ralph wrote: To accomplish this with CGI is to first emulate 5250 sessions between web pages with every variable, every aspect of a program, every file pointer position restored from whence the last screen was sent to that user by some CGI program, long gone. So an infrastructure to save and restore the entire program environment is required to do this or else the CGI programs could only do what they were designed to do, act unknowingly on each new web page coming in, blissfully retrieving whatever data was requested. Fine for anonymous browsing, worthless for business processing. So, don't use CGI. Use java servlets and have each session talk to it's own dedicated RPG server (...I'm guessing you still haven't read Joe's book?). After all, that's what 5250 does - one user gets his/her own RPG workstn program state (file pointers, variables, the "PAG") in memory. Ralph wrote: Who else uses web pages as a UI? Oracle. Why? Because like IBM, Oracle sells middleware. They don't really care so much about the UI as selling their database middleware. User interfaces are more of an inconvenience to people like IBM and Oracle. This is because Windows, Mac, HTML, etc already do GUI. Go with it. Why re-invent the wheel, or resusitate OS/2? If IBM invented their own GUI, it would be declared proprietary, not open. HTML is ubiquitous, the mostly commonly used UI on the planet for sure. Why shy away from it? Ralph wrote: But if IBM implemented a native GUI interface with a 5250 buffer API as I suggest, Eclipse could be the native UI but all of those desktop UI's could be supported. The key is a desktop GUI user interface to an OS/400 interactive session. This is *VAPORWARE* Ralph. How much longer will you wait for IBM to provide it? 1 year? 5 years? 10? 20? In the mean time, college grads and programmers overseas are blowing right by you, providing users with what they want TODAY, a GUI interface. Regards, Chris

**R.Daugherty** · 08-23-2006, 04:51 PM

Retrieve the Function Key Used on a Display File

Chris, I'm thinking on what you and Hans and Nathan at the other site had to say. But to clarify: Huh? This is not absolute - it depends. If you exit the CGI (RPG programs) with *INLR=*OFF (why wouldn't you? or have it exit with *INLR=*ON after every 50 calls, etc), the program remains in memory for that server job, waiting for the CGI traffic cop to route the next connection to it. These server jobs are shared amongst all CGI users. Servlets/JSP work well too, since they get loaded once and remain in memory. I understand that we can leave a CGI job in memory with *INLR off so that it doesn't have to be reloaded every web page. But the next web page that points at that CGI can be from any user, so I take it you reinitialize the RPG program with some call, or have an init routine that initializes all global variables, or write code carefully to ensure that all code is re-initialized before using? How do you handle that, Chris? So, how do you explain the success of web based transactional applications? You know, Dell, Amazon, Best Buy, E-bay, etc. Have you ever bought anything via the web? Are they operating in a house of cards, ready to blow over? Or have they proven that the web UI works? A servlet can keep track of the "current" page in the session object or use the Post-Redirect-Get technique so any web page contains current state. I don't know about the others, but Amazon and E-bay (along with Yahoo and Google) have entirely home grown world class infrastructures. One might say that's only because of volume, but it's also for response. An example was that I was a consultant in 2000 to Advanced Businesslink, which had their own customized native web server. I wrote the server side for the Jobs/400 site in RPG. In testing, a benchmark was a page response in 2 milliseconds for an error page from the web server, slightly more from my server program when a web page for that server came in. There obviously was no CGI and no job launched, just a feed from the web server to a dataq which I read and processed and wrote back. Data was merged from the dataq buffer into professionally designed web pages with custom HTML hooks for their web server. I'm sure the big boys do similar things. So, don't use CGI. I was responding to Hans, who noted that IBM had made CGI available. My comments were about CGI, not JSP. This is because Windows, Mac, HTML, etc already do GUI. Go with it. Why re-invent the wheel, or resusitate OS/2? If IBM invented their own GUI, it would be declared proprietary, not open. HTML is ubiquitous, the mostly commonly used UI on the planet for sure. Why shy away from it? This is a very important point. I listed the native GUI interfaces that other OS'es had, and asked why we are said not to have one, even though I have read in the past that we allegedly have XWindows and this is allegedly what keeps any version of Unix from being said not to have a native GUI interface. I did not suggest that IBM invent a new GUI interface, I listed the ones that do exist, and ask why our OS must be different. I repeat, our competitors are said to have native GUI interfaces, and none of them are said to have a web page as their native GUI interface. Why must we be different? I argue becaue IBM controls us because we're not open source and they are holding us hostage to push Websphere over the most advanced OS in the world, i5/OS nee OS/400. The difference is they bet the ranch on a J2EE web server, not the iseries400. For IBM, it will be web pages or nothing, not even green screens with their interactive tax, as long as Websphere is the purpose of their company and OS/400 is said to be good for nothing more than backing up Windows and Linux hard drives. As unbelievable as that is, just listen to them. Customers we don't have are. rd

**R.Daugherty** · 08-23-2006, 07:16 PM

Retrieve the Function Key Used on a Display File

Having re-read this, the customized native web server I refer to was an OS/400 HTTP server program, not another machine writing to an AS/400 dataq or something. It's all OS/400, I was just referring to the HTTP web server program as the web server. rd

**Guest.Visitor** · 08-25-2006, 06:00 AM

Retrieve the Function Key Used on a Display File

Bob Cozzi wrote: "Kids today" don't know what those indicators are used for Right on. Unlike other languages when it comes to RPG, "Kids today" have a lot to learn. I am trying to teach a rookie all about AS/400 and RPG. He is a C++ and Sequel Server programmer. While he can read and understand my code, he is clueless when it comes to the legacy stuff of the consulting company. I wish IBM would give us a subset compiler with good convertion tools. A subset that will not allow the S3x debris like *inkx.

Unconfigured Ad Widget

Announcement

Retrieve the Function Key Used on a Display File

Retrieve the Function Key Used on a Display File

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment