Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

DataQueues and Client Server

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

  • Guest's Avatar
    Guest replied
    DataQueues and Client Server

    Use sockets! There are too many limitation on dtaqs. 1. you can't wait on multiple dtaqs at the same time 2. they like to break during system crash 3. they are not platform independent 4. they are slower etc. etc. Forget DTAQs!

    Leave a comment:


  • Guest's Avatar
    Guest replied
    DataQueues and Client Server

    Will be developing a new application soon. The initial development will all be RPG IV. I plan to separate the "typical" rpg display program into two parts. One to do the actual work and another to just present the data and handle requests from the user. My goal is that in the future I can easily plug in graphical user interfaces (applet or application in java) or web access (applet or JSP). The 5250 screens initially developed should communicate with the back end process the same way the future UIs will. I was thinking about data queues, since there is support for them in the java toolbox. Of course, there are other ways I can think of: -Sockets (although, would this work for the native 5250 UI's where the backend is on the same box?) -Stored Procedures I'd like to hear some opinions on what others think is best... Barry

    Leave a comment:


  • R.Daugherty
    started a topic DataQueues and Client Server

    DataQueues and Client Server

    Hi Barry, I can offer this perspective from my experience with Jobs400 and Advanced BusinessLink Strategi web server. To leverage the ILE RPG / RPG III / Java server code across all interfaces, not just web pages, the servers are called with a program call and parms that designate the server name and a long field (9999) that would have been written to a dataq. In the past the data was really written to a dataq, but as they are doing some cross platform stuff exactly how the parm gets passed to the server can vary and is irrelevant. All of your servers are started up calling something similar to RCVDTAQ, and work the same way in looping through RCVDTAQ, SNDDTAQ equivalents. So the programs the server calls (equivalent to RCVDTAQ, then SNDDTAQ) and that the apps call (equivalent to SNDDTAQ, then RCVDTAQ) take the actual technology used (dataq's, sockets, etc.) out of the apps, in whatever form they take. In my case, I tested web page initiated calls with the same calls from within a green screen program, and put up some screens for entering input and displaying the results. As you know from what you're doing, at no point does the server programs have anything in them concerning the interface or type of output, be it web pages, green screens, or a client program. But the app programs also don't have anything in them about dataqs or sockets as well. Now this is ok for web servers and AS/400 programs in that program calls can be designated, but may not be too great for calls from elsewhere. My personal opinion is adding another dataq layer in which to write to and which will have a number of RCVDTAQ programs serviving it could then make the call to the server interface. After the server returns, it could then write results with SNDDTAQ and out to the client if the client (other than a web page or AS/400 program) has a DTAQ component. When a client environment doesn't have a DTAQ component, a program receiving sockets calls could accumulate the buffer and call the server interface instead. Of course, if this has to be done for even one type of situation anyway, it might be considered to be used universally, or it could feed into the front end dataq layer as a sort of dataq interface emulation. This may all be self-evident, but thought I'd mention that that one extra encapsulation of the technology used (dataq or sockets) really adds a lot of flexibilty. Regards, Ralph
Working...
X