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.
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: Thursday, 5 April 2001 11:36
Subject: display screen in a program, but not used when program called from batch
I've written an RPGIV program that uses a display file to get information
if the information is missing from a record.
In one circumstance I wish to schedule the job to run in batch at night. I
have already ensured the information is not missing, so the display file
will not be needed. However the batch job fails anyway.
Is that what is supposed to happen, or is there another error I am not
Is there a way to resolve this issue without writing a second identical
program sans display?
Thank you for your ideas, they are always welcome.
| 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: email@example.com