Thanks again.

The ’9C’ file status (“Acquire failed; session was not started.”) plus the “COBOL” tag on the question pretty much says this is all COBOL. That should make it easier than trying to do the same with RPG II/III, but still probably not a trivial task.

If the program already does its work in Working Storage, it’ll be easier. If it doesn’t, then making changes to reference definitions in Working Storage should be the first step. Then it could mostly be conditioning file I/O on some external element, perhaps just a test if it’s running in batch or not.

And, of course, some kind of entry point into the program would have to be established along with appropriate exit… but that’s just a “small matter of programming”.

Tom

You want to use this hypothetical subroutine to validate data coming from the screen via the screen format record, or to validate data provided from a database file record.

It seem to me that you need 3 functions – interactive that callsa validation module, batch file reading which calls a validation module, and the validation module.

Whether you abstract the validation into
- /COPY source
- a *PGM
- a *MODULE
- a procedure and *SRVPGM

is immaterial;. I guess you’re starting from RPGII or III in terms of design, so gathering all the input / output and return code(s) into a suitable interface / record layout / data structure (your choice) should be simple, if exacting. Testing such a routine is easy and precise. Testing the calling routines becomes equally simple.

If you spend some time with the architecture and design of the functionality, then programming will be straightforward. Overall savings in lifetime costs (and development/testing costs) accrue from making this simple and testable right up front.

But the question isn’t totally clear.

…to gain access to it’s field names.

You don’t have to open a file to get access to field names. You seem to want access to field values rather than names, and you can use the field definitions to store and retrieve values without opening the file.

Your big problem seems to be that the program directly references fields under the FD rather than in Working Storage. The record(s) defined under the FD is essentially in the I/O buffer. The program probably shouldn’t be referencing fields there to begin with. Instead, definitions should be in Working Storage where the program can READ … INTO and WRITE … FROM.

If all work is in Working Storage, the file doesn’t need to be opened. Just bypass the I/O statements.

Tom

I first load the data from my external source into the appropriate databases. I then call the interactive module to editupdateprocess the data. I set a switch to turn off the actual screen displays when extrnal data is being processed. This works fine when I call the job from my desktop, but fails in batch because of *requestor. I just need a way to get the screen fields active without actually readingwriting to the screen. I think OVRDSPF may help, but i am not sure what to do.

If we want to open a display file from a batch job, it must acquire a device.
and there might be need to handle a display file in USROPN mode based on the type of job(Batch or Interactive).

Pradeep.