Re: Threadsafe

Thanks for the response on threadsafe. It confirmed my suspicions. I worked for Control Data back in the 70s and they had the same concept  whereby a number of processes could all share the same executable by each having their separate set of 'state' values and instruction pointer swapped between disk and memory as the time-slice was used up........and I thought Java was a new dimension in programming.

The reason I asked the question is because we've separated the presentation from the process with the intention of passing the screen buffer as an XML message to an application server and then as a web page to a browser and I've just started thinking that the AS400 method of controlling screen navigation at the host end can be completely subverted by the use of the browser navigation controls. How are these reconciled? In our application an enter key plus correct validation results in a 'next screen'. An F12 results in the previous screen traversed. Some programs are multit screen in which all edits must be correct before the final commitment to the data base is secured. If the traversal is all managed at the browser or server, then some other sort of control needs to be effected.

In the normal 5250 world the program generally controls what part of the application the user goes to next based on various inputs. In the web world the user controls where they want to go. This is ok for a purely inquiry application, but for an updatable application we need to ensure that ALL edits over all screens have been traversed before allowing the commitment of the logical transaction. What if the user goes back and changes a previous entry? Does this mean that if i want to web enable our traditional multi-screen application I need to create some sort of control module that keeps track of the individual screens that the user has traversed correctly, albeit in random order?

Another observation. I work for a General Insurance software product. When in selling/marketing mode we present our green-screen functionally rich to the point of exotic product to a  new generation of managers who equate green-screen with punched cards (if they know what a punched card is). We are in competition with products which may have one tenth the functionality, but guess which one the business managers prefer? The one that looks like the operating system they use on their home computer. The issue of speed of data entry does not win sales. The problem with speed and GUI is the simple act of removing the hand from the keyboard to manipulate the mouse. But then there are short-cut keys. Or how about a mose pointer which is manipulated with the feet leaving the hands to concentrate on the key board? The argument of what does GUI add is arcane. It's the same argument I heard from assembler programmers. Oh! You can multiply in one statement? So what advantage does that give? It only takes me 10 small lines of assembler. I can write them with my eyes closed and my mind in the tropics. Ultimately the market will decide where they put their money. Does anybody on this list really believe that in 10 years time there will be applications running on the AS400 with a list of menu options, each numbered and a screen expecting a menu option number to be entered by the user? Straight-line data entry via a GUI entry is not necessarily an oxymoron.

Back to my original request....is there any reference material anywhere which may provide guide-lines for reconciling a traditional RPG screen flow scenario with the pesky habit of users to go whereever they like in a businesss application?

Perhaps this is one for IBM. We've followed their guide-lines, we've layered our application, we're going to use websphere. So how do I manage the random anarchic behaviour of the user goinmg where they want to go rather than where the application wants them to go?

 
Regards,
Mike Pantzopoulos
   Email: mpantzop@csc.com.au