• Subject: RE: display screen in a program, but not used when program called from batch
  • From: "Pantzopoulos, Mike" <mikepantzopoulos@xxxxxxxx>
  • Date: Thu, 5 Apr 2001 19:33:24 -0400

Title: RE: display screen in a program, but not used when program called from batch

Why not take the opportunity to truly layer the application?

Remove the file declaration and replace the screen verbs with a call to an external routine.  In that routine declare the screen and create a case statement that switches to the correct verb dependent on the request code passed to it. (I've done this using the original verb as a request code to our routine). For example, in the simplest case 'EXFMT' would be the request code.

Use a DS to communicate the between the process and display code. The DS can be generated by a tool which reads the screen object and creates a DS source member which can be compiled. The field names in the DS are the same as the field names in the screen object.

If you want to get really smart, generate XML tags to the DS. This might be useful if the eventual User Interface is to the web.

Then you have an application which doesn't care where it gets an input from. The same process code can be used for a variety of interfaces. Why write it twice? The input via the DS back to the process code can come from a 5250 session on the same machine. Might also be a 5250 session on another machine (via MQ Series), or it might be some server which is serving up information to the web (AS400 server of course). With a suitable wrapper, it might also be an EDI interface.

This is probably way beyond where you envisaged the original question going, but it can be achieved.
-----Original Message-----


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].