Can I open a display file from a batch job?

25 pts.
Tags:
Display File
I need to open a display file from a batch job to gain access to it's field names. Currently I receive fiel status '9C'. This program is usually used interactively.

Software/Hardware used:
Iseries 400; Cobol

Answer Wiki

Thanks. We'll let you know when a new response is added.

By default a batch program cannot do an EXFMT command because it does not have a DSPF opened.
I know there is a way to allocate one but it has been too many years and I do not remember how.

That being said, I would say you may have a bad design in your process.
What are you trying to do?
You can interact with a batch program in other ways, like messages, *DTAARA, and others.
Tell us what/why you are trying to do and you will get specific advice.

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • deepu9321
    We can't directly open a display file from a batch job. It will display the following error with error code 'CPF4103' "Device *REQUESTER not found while opening file DISPFILE in LIBRARY" 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.
    4,235 pointsBadges:
    report
  • Developerallen
    I trying to use the existing logic in a very large program to edit data coming from an external source. I don't want to rewrite a very complicated program, nor do I want to have a copy that then must be maintained. 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.
    25 pointsBadges:
    report
  • TomLiotta
    You can open a display file in batch if you use the ACQUIRE statement to acquire a device to display the display file on. Of course, that brings a few logic changes to say the least. 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
    125,585 pointsBadges:
    report
  • Yorkshireman
    If I understand this, you have a function which reads/writes to the screen, and validates the data - hopefully in a subroutine. 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.
    5,580 pointsBadges:
    report
  • TomLiotta
    I guess you’re starting from RPGII or III in terms of design,... 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
    125,585 pointsBadges:
    report
  • Developerallen
    Thanks for the suggestions. The simplest solution was to just move the DDS for the screen file to the working storage section and do "read into" and "read from" for the screen IO's. Thanks again.
    25 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following