Sample Cobol Program Read And Write Into File
I am using Kaplan's AS/400 App dev using COBOL/400. From the examples, I created a display file called HELLOWORLD using SDA. SDA created the following files YOURLIB/QDDSSRC/(HELLOWORL D DSPF TEXT-) AND YOURLIB/(HELLOWORLD.FILE DSPF ) Now I want to write a COBOL program that opens the diplay file(YOURLIB/(HELLOWORLD.FILE DSPF )) and displays the record format on the display. I know the COBOL PC systax as FILE-CONTROL. SELECT FPTR ASSIGN TO 'C: MYFILE.TXT'. THE BOOK SAYS FILE-CONTROL.
COBOL Simple, Single File Examples of Program Logic source The American Programmer. Processing with each record read. Our sample program will just write. Jan 08, 2008 COBOL/400 file read/write. Now I want to write a COBOL program that. Some of the generic characteristics get retrieved and compiled into the program. COBOL programming site with a full COBOL course as well as lectures, tutorials, programming exercises, and over 50 example COBOL programs.
SELECT FPTR ASSIGN TO WORKSTATION-HELLOWORLD. Please explain why WORKSTATION-HELLOWORLD and not YOURLIB/HELLOWORLD is used to open the file.
Hi The as400 works on a library list structure; the basic structure is: System libraries Current & product Library User libraries Use DSPLIBL to look at them. When the system needs an object it looks thought the library list to find it and used the first one it comes across. The COBOL specification is defining a “WORKSTATION” file. This is an as400 object of “.FILE” with a sub attribute of “DSPF”. The system will look through the library list for this object. When you create the file you need to tell it what library you want to place it in; that is what you are doing with the “YOURLIB/(HELLOWORLD.FILE DSPF)”. You simply add YOURLIB to the library list for the COBOL program to pick up the file.
I hope that this explains it! Dave, I am seeing WORKSTATION-filename and DATABASE-filename. May be if you explain a bit these differences, I might understand why in the program select statement the file is identified as WORKSATION-HELLOWORLD and in the Library listing as HELLOWORLD. It might have been easier for me if the program was written as SELECT FPTR ASSIGN TO HELLOWORLD.
Instead of SELECT FPTR ASSIGN TO WORKSTATION-HELLOWORLD. And the file is listed in the YOURLIB library as HELLOWORLD Thanks Dave for the help, I am learning a lot for a short period of time. Hi there are several different types of file on the system 1) Physical file - this actually holds data SQL table 2) Logical file - or index this holds pointers to the data held in a physical file.
SQL view or Index 3) ICF file - communications. 4) Printer files - Reports 5) Display - screens etc.
I guess anything that has IO is defined as a file. Each of these files has special attributes as defined with-in the DDS. The AS/400 is also very integrated in its mak-up, the compillers have direct access to the database and other type of file objects.
As these are all '.FILE' type objects the DATABASE/DISK/PRINTER/WORK STATION is a compiler instruction to tell the compiler what type 'FILE' it is working with. A good example of this is 'Sub Files' these are only available id workstation files, so if you tried to perform a subfile operation on a database file the compiler would tell you and not compile! Libraries hold the actual object. The same object can exist in multiple libraries - ie Live environment and a Test environemnt. Yassin: General additional notes for the archive.
Maybe others want to add more. The WORKSTATION-, DATABASE- and other qualifiers tell the compiler what kind of I/O is going to be performed. You might think of it as a way to tell the program what device drivers to bind into the program object at compile-time. The name of the file tells the compiler what the name of the object is that it should search for. The library name isn't important for a reason I'll mention in a minute. A WORKSTATION- file is an extension of a.FILE object. It has an extended attribute of 'DSPF' for 'Display file'; you can see that attribute value when you list.FILE objects with commands such as WRKF.
PRINTER- files have an attribute of 'PRTF' and might be a good example of what happens because of this attribute. There are two very general and broad kinds of printer files - those that are pure text and those that have embedded graphics. The handling of data that is sent to PRTFs is very different between those two types. When a PRTF is created, a bunch of different characteristics are defined and get compiled into the PRTF itself. When you compile a program that opens that PRTF, some of the generic characteristics get retrieved and compiled into the program. Most particularly, the data elements and print record formats are retrieved. The 'format level identifiers' are retrieved at the same time and stored in the program along with those record formats.
Give More Feedback
(You can see the various level identifiers when you display the file definition with DSPFD. You can see them as part of the program object when you display program references with DSPPGMREF.) The library is not stored with the program because of a concept based in 'device independence'. You can write a program to handle a file with particular characteristics by creating a file definition that has those characteristics and naming that file in the SELECT ASSIGN clause. The purpose of that file is to hold characteristics for compile-time. Because of 'device independence', you are not required to access that particular file at run-time. All you are required to do is access any file with the same characteristics.
You can access a file of the same name in a different library, you can even access a file of a different name. You specify which file by executing an override command before opening the file. For a DATABASE- file for example, you could override with a OVRDBF command. For a WORKSTATION- file, use a OVRDSPF command. For PRINTER-, use OVRPRTF.
As long as the file that is accessed has the same value for format-level identifiers (and is the same type of file - database, DSPF, etc.), the program won't even notice. It will handle any instance of a matching file. (It's also possible to handle files that don't match, but that's only for specific advanced uses really.) If you don't supply any override, the file that will be used will be the first file of the same name that is found by searching through the library list of the job that runs the program. By changing the library list, you can switch between test and production environments for example. Commonly, a job description is used to determine the job's library list.
(The library list is really little different from a PATH almost anywhere else.) Now, when a file is actually opened, all of the characteristics get retrieved. These characteristics are stored in hidden data structures within the job itself. For a PRINTER- file, a critical kind of information is the actual device type that the output should be created for. Is it a character based printer? A laser printer? That makes a big difference at run-time.
Read And Write Extension
You might replace a printer some day and get one with a new capability. Rather than recompile programs, you can simply execute a CHGPRTF command for printer files that that work against that printer and specify the printer type. The next program that opens that printer file will automatically learn how to format for that printer. The overall idea is called 'external file descriptions'.
Only the basic file type and the formats of input/output data become part of the program object. Those are brought in from the named file at compile-time, and they're brought in from the file definition which is separate from and external to the program. At run-time, the full details are retrieved from whatever external definition the program is told to use, either by use of an override or by searching the library list.
By keeping file definitions external to the programs, you can make changes to the external definitions without recompiling the programs. Further, all of the buffer definitions are also brought in automatically at compile-time. You don't have to code a bunch COBOL data definitions - those are already in the file itself. All you must code in the COBOL program are COPY statements to tell the compiler which record formats you are interested in and where to put them in Working Storage (and/or under which FD).