|
I understand your points. And commands are great prompting utilities and, in my opinion, are terribly underused. I don't buy your point about the interactive error handling being 'effective'. Having users make the decision: C,D,I,R is not leaving the problem in the best hands. Dang, but if I don't wish my colleagues used more time, themselves, before taking an option. a) Gee the tape initialization failed for last nights backup. Let's take an R. DURING THE BUSIEST PART OF THE DAY! b) Error on a variable, let's take a C, INSTEAD OF A 'D' TO DUMP THE VARIABLES! And Steve, while you avoided talking about DDS, and stuck with Commands, (smart move, by the way) I bring up the point that maybe we stick with what we are familiar with. Just some simple glancing into html makes me drool that DDS had such support. Not knocking you buddy, I don't know your background at all. But getting back to Joe's points. I feel that anything that can be run in batch, should. Like most of the printing that your commands generate. As much as you can reasonably do to separate the business logic from the presentation, the better. Rob Berendt ================== A smart person learns from their mistakes, but a wise person learns from OTHER peoples mistakes. "Steve Richter" <srichter@AutoCoder To: <MIDRANGE-L@midrange.com> .com> cc: Sent by: Subject: Re: IBM getting rid of RPG owner-midrange-l@mi drange.com 07/30/2001 11:39 AM Please respond to MIDRANGE-L Rob, The Joe Pluta approach adds value/functionality to our platform. That is a good thing. And as he and you point out, there are solutions to each situation I describe. but there are also costs. Simplicity is one cost. I can use sda to create a simple menu, create commands that front some report producing rpg pgms, add these commands to the menu, insert some selective prompting to the commands and in little time I have something functional and easy to use for the user. To move this to the web, out of the reach of cfint, I have to scrap all of this. Something that was simple and effective has to be replaced. The web solution, in my view, has to be just as simple. re wrkoutq, wrkwtr, wrksbmjob ...The possible loss of a common user interface is another cost. If I can launch ops nav with parms that tell it to display a particular outq, that would be an adequate alt to "wrkoutq outq(xxxx)". Writing a custom java script version of WrkOutq is a solution, but the cost is likely to be the common user interface. Each web page version of WrkOutq will work differently. End result: user confusion. ( There is also the $ cost of the custom approach. Writing the web version of WrkJobq takes time = money. WrkOutq ??Outq(xxx) is free. ) re exception handling. consider a cl pgm. the default excp handler enables cancel, ignore or retry of a failed stmt. Enables you to investigate the cause of the error, then retry or ignore the error so the pgm can continue running. Very simple and effective. Any excp handling code you put in the pgm actually interferes with this process. I welcome a technical discussion of how to link the interactive web user with the excp messages of the batch running pgm, but be prepared for a long discussion<g>. All these problems because ibm wants to play its cfint games. Steve Richter -----Original Message----- From: rob@dekko.com <rob@dekko.com> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com> Date: Monday, July 30, 2001 11:13 AM Subject: Re: IBM getting rid of RPG > >Steve, > >Granted some things will be done in interactive, however not everything >that is currently done in interactive needs to be there. > >I think what Joe is saying is that if you key an inventory transaction and >it has to update 5 files and calculate new balances and zap off an email to >someone that we just reached a negative balance, and , and , and. Then >perhaps you would be better served to break this up. The presentation part >will do the screen entry. This sends the process off to a data queue or >something to do the rest of the process. Now if you've done this right, >and some snot nosed kid comes along and wants the presentation done in web >or NT client than you already have the back end processing done. And you >get to keep your back end in RPG, if you desire. Which is where any biased >RPG programmer will tell you that the only competent business programming >can be coded. > >Have you ever written a batch process before? Yes, on occasion an error >will occur. But you've handled this right? There must be a zillion >techniques. No difference in this process. The beauty of it is that the >user won't be guessing as to what option to take. Your message monitoring >will notify someone better able to handle the situation. > >Some people really may wish to study alternative methods of presentation >than DDS. For example the hoops that I had to jump through to maintain a >variable length field for comments which may exceed a screen size, was >enough to vomit. This versus 1 single line of html. > >Also, some of the commands you mentioned: WRKSPLF, WRKWTR, and more, >WRKSYSACT, etc are probably better served in Operations Navigator. Think >of all the stuff IBM is giving you for free! Stuff that they charge you >for in 5250 land. For example WRKSYSACT requires that you purchase >Performance Tools. The functions of this are given free with Operations >Navigator. > >Rob Berendt > >================== >A smart person learns from their mistakes, >but a wise person learns from OTHER peoples mistakes. > > > > "Steve Richter" > <srichter@AutoCoder To: <MIDRANGE-L@midrange.com> > .com> cc: > Sent by: Subject: Re: IBM getting rid of RPG > owner-midrange-l@mi > drange.com > > > 07/28/2001 01:32 PM > Please respond to > MIDRANGE-L > > > > > > >Joe, > >What do you do about > > cmd prompting > > any ibm cmd like WrkSplf, WrkSbmJob, esp WrkOutq and WrkWtr > > Receiving a break message > > Exception handling - rpg or cl pgm hits an unmonitored exception msg. >The ibm default exception handler takes over and wants to prompt for >Cancel, >dump or ignore > >I like your concept, but in practice these situations have to be dealt >with, >No? > >Steve Richter > >-----Original Message----- >From: Joe Pluta <joepluta@PlutaBrothers.com> >To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com> >Date: Saturday, July 28, 2001 1:55 PM >Subject: RE: IBM getting rid of RPG > > >>There are ways around the interactive tax. In fact, I'll be doing a >seminar >>on exactly that topic at COMMON. The basic idea is to modify your >programs >>to run in batch and talk to a data queue instead of a display file. Once >>you do that, you can pretty quickly attach a user interface, either thick >>client or thin. A thick client can be written in VB or Java, or you can >use >>a servlet engine such as WebSphere or Tomcat to run your applications via >a >>browser. It's fast, powerful, flexible and relatively painless. >> >>This way, your primary business logic is still written in RPG, which I >>contend is the best language for defining business rules in the business, >>primarily because of its tight integration with the database. And, once >>you've started separating your business logic from your presentation, you >>can start looking at moving towards a true client/server architecture, >which >>is where I believe the iSeries will truly outpace any other platform. >> >>Joe >> >>> -----Original Message----- >>> From: owner-midrange-l@midrange.com >>> [mailto:owner-midrange-l@midrange.com]On Behalf Of William A Pack >>> Sent: Saturday, July 28, 2001 11:09 AM >>> To: MIDRANGE-L@midrange.com >>> Subject: IBM getting rid of RPG >>> >>> >>> I liked Mr. Rockwell's comments. IBM is trying everything >>> to get people to >>> abandon current applications and migrate to something they want to sell, >>> like Java or Domino. They are good alternatives for new apps, >>> but if I have >>> a business running for 5-10 years on good software, why should I >>> change just >>> because IBM wants me to? IBM is going to piss off quite a few >customers, >>> who will remember the favor that IBM did them by jacking up the cost of >>> interactive workload. If they have to change applications, my >>> guess is they >>> will be implemented on a cluster of Wintel boxes, just to return the >favor >>> to IBM. I really want to now the technical reasons IBM has for costing >on >>> interactive features. They claim it is harder to do 5250 now that 3 >years >>> ago. Why? >>> The System 3/x family was sold as a programmerless systems. >>> The AS/400 was >>> sold as a system that will maintain investment in applications >>> and business >>> practices. Now, the only thing that sets the 400 apart from the sea of >>> Intel based clones is the single manufacturer. Looks like the future >>> belongs to Wintel and C#. >> >>+--- >>| 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 >>+--- >> > >+--- >| 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 >+--- > > > > >+--- >| 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 >+--- > +--- | 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 +--- +--- | 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.