Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Strike It Rich! Reversing the Trend of Web Clients

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Strike It Rich! Reversing the Trend of Web Clients

    I agree with that. Windowing is used and I get asked about it in interviews. Mouse I haven't seen a need for, but a new interface should make function key buttons clickable anyway. Menuing I haven't used. You have to give people a reason to take their hands off the keyboard and onto a mouse to use a mouse, where getting "focus" may be a reason but not a productive one. A productive reason would be mouse driven interaction with other desktop apps such as drag and dropping data, resizing subfile table columns, clicking on a column to bring up a different read only view of the subfile sorted in the order clicked, etc. The main thing is to get a standard Java interface out there where a mouse can be used or not used, but if there's a productive way for people to use it then we'll program for it. rd

    Comment


    • #17
      Strike It Rich! Reversing the Trend of Web Clients

      I'm going on the road again this morning, returning from a trip where I didn't get an RPG programming job yet again after more than a year. On the other hand, calls from recruiters picked up slightly after Labor Day and increased dramatically after New Years. I even thought I would get a paying job again. Oh well. If not for all my loans being in default, this is a wonderful opportunity for me. I got a book written that I'm proud of and I've almost completed rewriting my Double Deck Pinochle game in Java for use on internet game boards, just the start of a lot of ideas I want to work on. Are any of them an interface for the AS/400? No. I'll do a lot of experimentation on interfaces for my projects, the same as I'll be experimenting with replacements for DB2/400 and every other aspect of OS/400 that will no longer be available to me and people who will want to use my software. I will do my best to emulate it and have been researching on how I may go about it. I have a roadmap, as IBM would say. But the Java interface for the AS/400 must come from IBM, must be open source, must be formatted for along with HTML and 5250 in EXFMT by OS/400, and must ship with the AS/400 to be viable. Otherwise the AS/400 will be about as viable as my career. rd

      Comment


      • #18
        Strike It Rich! Reversing the Trend of Web Clients

        But the Java interface for the AS/400 must come from IBM, must be open source, must be formatted for along with HTML and 5250 in EXFMT by OS/400, and must ship with the AS/400 to be viable. What's sad is that the Java interface already exists and comes from IBM and is open source. It just isn't going to be implemented via EXFMT, and if you could get past that you'd be thrilled with what you can do on the box. Joe

        Comment


        • #19
          Strike It Rich! Reversing the Trend of Web Clients

          'How about this now: The vast majority of AS400 programmers if given enhancements to 5250 capabilities will use them. Dave ' I don't agree with this. I have been to many shops and DDS isn't exploited to the level it could be in not one. It is not the developers who are driving that decision, it is our customers. They (where I have been don't want fancy on their green screen, they don't want an abundance of colors, they want simple and easy for the old data entry personnel to continue doing business and not have to be retrained into something they don't want). They want everything to stay as it always has been (if we add a screen, they want to perform just as the other 999 screens do).......now on the other hand where they want new and fancy and a lot of colors they don't want it to look or feel like the 400 (and these are the same customers). They want it to function and look like windows (because thats what they want). And the ones that want, sign the checks, so the ones that do, do what they want, and they don't want enhanced DDS. So, we have been part of the problem, they don't want to be tied to a transaction, they want to click a mouse and get what they want no matter where they are in a transaction, and DDS and ExFmt are not the way to deliver it and 'they' know it. And so must the time come for 'us' to know it too. Show your hands, how many of you are working on enhancing your DDS on the clock or after hours? And how many of you are working on other things instead to try to stay employed? or on contract? This only counts if you are working on anything new, because there will be maintainance forever on RPGII and whatever else is old.

          Comment


          • #20
            Strike It Rich! Reversing the Trend of Web Clients

            When our users want green screen aps for data entry they don't want change. For the most part they are happy with 3 colors, White,Green, and blue. We have to fight with some of them to accept any change good or not. When they want new ones GUI stuff, Easy400 works great and they are happy with it. IBM's attempts at changes in the DDS produce crummy results in my opinion. That's why I don't a lot of the graphic features. On the S/36 I could write a document and have it show the values in a table file as a part of the help function. They ran away from that idea. They built all kinds of neat functionality into that word processor and then didn't tell anyone. Then the took it away because, "Nobody used it". Help text is nice, but unless you build a lot of detail into it, it is quickly out of date and useless. Having help is nice, but most shops I have worked in are more concerned about getting programs written than writing help. Radio buttons and the other attempts to add GUI items to the screen don't work on everything, and I don't like the way they look. I don't like the newest pull down menus. They are only a halfway attempt at GUI. I don't use them because I don't like their implementation. If they came out with a real GUI interface that looks good and runs efficiently, I would use it. Since I don't believe they are going to, I will settle for CGI & Java, using products like Easy400

            Comment


            • #21
              Strike It Rich! Reversing the Trend of Web Clients

              I've used Mouse and Menus in interface design extensively in the past. A typical use is to provide menus which allow the user to filter the contents of a subfile, for example one drop-down menu may provide selection critea by product group and onother by order status. Mouse can be used to allow the user to click a column in the subfile to have the subfile sorted in that sequence. Granted, it's possible to do this using Function Keys (since MOUBTN emulates an F-Key anyway) but it's easier for the user to use the mouse than to position the cursor in the column and then press a function key. Giving the user the flexibility in both functionality and useability is the key thing. Stuart

              Comment


              • #22
                Strike It Rich! Reversing the Trend of Web Clients

                I have a strong feeling that tinkering around with the 5250 interface just isn't going to make very many people happy. It doesn't deliver the goods to the clients, and the administrative and financial types won't pay for it. The issue is far deeper than the simple appearance of the screens, too. Issue 1: 5250 is a proprietary interface, and it's very far from universal. The 3270 interface is similar, and from IBM, but obviously not exactly the same. The DEC world was all ASCII VT-### terminals, there were Wyse terminals and on and on. None became truly ubiquitous. The reality is that Windows is everywhere, HTML is everywhere, and you can make weaker cases for Mac, the various Unix/Linux GUI's, and so on. Issue 2: Location independence. The Internet has it, and people want it. Universal network connectivity is here based on TCP/IP. Sure, 5250 can be disconnected from it's SNA roots and routinely is these days. That's not the point. You want to be able to log in to your systems from any old computer with an Internet connection and a browser. Aha you say, our systems are inward facing and we only serve them up in corporate settings that we can control! Sure, that's what you do now, but have you ever thought it might also be the case that you can't do it any other way, so you never try? And when someone asks, you simply say no? Don't your staff ever travel? 3). Too many weird interface issues that decrease user productivity. The 5250 interface is mostly used in a way that's modal, but GUI's have shown the value of non-modal interfaces. I've even written 5250 stuff that's non-modal but the reality is that most software on that interface platform is modal. What business value did locking the keyboard ever provide? Have you ever tried to train a new user and needed to explain the Field- key? And how does anyone justify turning the rightmost digit of a numeric field into a } character? The client should enter the facts and the computer should worry about formatting issues. Automatically! I say that people will accept change that improves their work situations and their lives. Provide a clear benefit, explain it effectively, and you will get where you want to go. The thing is, that has already happened with graphical interfaces and universal networking. The public and business expectations have been raised to expect these new capabilities. Fiddling around with 5250 is closing the barn door after the horse has left. Sure, you can re-write everything using DDS keywords that are rarely used, or don't even exist yet, but you've exceeded the threshold of tolerance for change. The correct business approach under those circumstances is to say: If we have to change everything anyway, then let's really open it up. We have strategic needs that we would like addressed. The technology becomes secondary. What technology helps us to get the business power and flexibility that we crave? Most times, the answer list won't include 5250.

                Comment


                • #23
                  Strike It Rich! Reversing the Trend of Web Clients

                  > And how many of you are working > on other things instead to try to stay > employed? I am. I don't know of any employer who will train me for new stuff on their dime. --buck

                  Comment


                  • #24
                    Strike It Rich! Reversing the Trend of Web Clients

                    I read all the responses. Great to hear different opinions on this. I guess when I say XML formatted 5250 superset for the new interface it doesn't explain it very well. It describes what 5250 is doing on the green screen with keywords but would be rendered in Java or any other GUI interface driver programmed to respond to keywords, so for example, the way buttons and menus look in 5250 emulation is totally irrelevant. The menus and buttons would be rendered in the desktop OS look and feel provided by IBM's Eclipse GUI in a new interface. It would also render less than satsfactorily in a 5250 emulator if someone were using a 5250 emulator, in other words, totally backward compatible, but the point of a new Java interface is to render beautifully per desktop standards as we all would want and expect. The point is that they are all just interface commands, transmitted in 5250 binary, XML 5250 keyword superset, HTML, and any other format needed, provided by IBM in OS/400. We just direct in DDS. How well it looks on the desktop will vary based on the interface. The new Java interface should look and work like a Windows program in Windows, and IBM has seen to that with Eclipse and their desktop OS groundedd GUI. I am talking about modal programming, however. Event driven programming may be fine for some things but it hasn't proven to be fine for ERP transaction processing. Nothing I suggest prevents other types of programming, but client/server has largely been proven a failure for enterprise transaction processing. It has only been the interface that has been suggested to change for us, primarily from 5250 green screen to HTML web page. The XML 5250 keyword superset with extensible keywords would be an important breakthrough for AS/400 programming in my opinion. As keywords, it is largely irrelevant that they were designed for a green screen and in fact they of course wouldn't be transmitted to an existing 5250 binary emulator or terminal. The intent of the design, such as text field 1, would precede the data along with positional data on the green screen. A component in a GUI interface would be rendered in any interface receiving and transmitting the XML stream. In fact, I argued in my three IMHO columns on this that it would enable machine to machine transaction processing, and since then more wrappers such as SOAP have beome more dominant for this, but whatever the wrapper, even a faked 5250 session, the XML keywords opens our programming and our box to become what one would hope would be the predominant transaction processing OS, that is, OS/400. The flexibility , however, must be provided within OS/400 in EXFMT for solid RPG transaction processing that becomes interface independent on the fly. Others obviously disagree. Another thing I argued for in my columns was a companion sockets session with each interactive session signon. I think data drilldown is imperative, and I think the way to do that is to feed off the transaction screens and provide query views based on point and click at transaction data, and from there drill into as many views as desired. This in no way affects the original transaction logic which merely waits for a response but it does provide supplemental real time information to the transaction processor based on the same authority restrictions of the job being performed. If there is some fundamental interface component that is not addressed or implied by 5250 DDS, then let's add it to DDS and design for user interaction within transaction modal programming to any type of interface simultaneously based on connection type. I don't know of any aspect of an interface that isn't already covered, and what I describe is an orchestration of interface components rendered via XML to any interface programmed to respond. The fact that it is backwards compatible via 5250 binary and that all existing 5250 programming is forward compatible via XML wrapper keywords is also important, but not as important as how those buttons and menus look if no one wants to use it. The Eclipse Java interface would deal with both aesthetics and interoperability with other desktop apps that a browser doesn't. All we need to do is keep writing that solid RPG transaction logic and let it be rendered as desired. OS/400 would do the rest. rd

                    Comment


                    • #25
                      Strike It Rich! Reversing the Trend of Web Clients

                      0

                      Comment


                      • #26
                        Strike It Rich! Reversing the Trend of Web Clients

                        Buck, I do. chuck Opinions expressed are not necessarily those of my employer. "Buck Calabro" wrote in message news:[email protected] ahGHajS... > > And how many of you are working > > on other things instead to try to stay > > employed? > > I am. I don't know of any employer who will train me for new stuff on > their dime. > --buck > >

                        Comment

                        Working...
                        X