• Subject: RE: Non-Join multi-PF logical file format
  • From: "Stone, Joel" <StoneJ@xxxxxxxxxxxxxxxx>
  • Date: Wed, 24 May 2000 13:55:51 -0400

Yes - this works fine in COBOL.
R REC1              
  FLD1          10  
R REC1              
  FLD1          10  
 R REC1                      PFILE(FILEA FILEB) 
 K FLD1                                         
       IDENTIFICATION DIVISION.                                    
       PROGRAM-ID.                     FILEABTEST.                 
       ENVIRONMENT DIVISION.                                       
       CONFIGURATION SECTION.                                      
       INPUT-OUTPUT SECTION.                                       
      *    EXTERNALLY DESCRIBED PRINTER FILE                       
                                       ACCESS MODE IS SEQUENTIAL   
                                       ORGANIZATION IS INDEXED     
                                       RECORD KEY IS               
       DATA DIVISION.                                              
       FILE SECTION.                                               
       FD  FILEAB.                                                 
       PROCEDURE DIVISION.                                         
           OPEN INPUT FILEAB.     
           READ FILEAB            
           DISPLAY REC1           
           READ FILEAB            
           DISPLAY REC1           
           CLOSE FILEAB.          
           STOP RUN.              
fileA contains 1 record:  "FROM FILEA"
fileB contains 1 record:  "FROM FILEB"
Run-time log:
call fileabtest
Can I get back to work now??  :)
-----Original Message-----
 From: David Keck [mailto:dkeck@idt.net]
Sent: Wednesday, May 24, 2000 1:58 PM
To: COBOL400-L@midrange.com
Subject: Re: Non-Join multi-PF logical file format

There were several responses to my original question, (for which I am thankful), but they are nonetheless missing the mark.  The example shown at the bottom of this message from Finucci Domenico is a typical non-join multi format LF where each format refers only to a single PF.  This is not what I am interested in. 
Consider the following example instead.  Note that a single LF format is based on two PF's.
R    RFILE1    PFILE(PF01 PF02)
A    K    Field01
A    K    Field02
Files such as the one I describe above must be defined such that all the fields in the LF must also exist in ALL based on PF's.  My question is whether COBOL can compile and work with a file which is defined in this fashion.  I know the file could be redefined as a join to circumvent the problem, but the question still stands. 
----- Original Message -----
Sent: Wednesday, May 24, 2000 6:09 AM
Subject: R: Non-Join multi-PF logical file format

yes, it does.
Let's take an example and suppose we have the following LF
R    RFILE1    PFILE(PF01)
A    K    Field01
A    K    Field02
R    RFILE2    PFILE(PF02)
A    K    Field01
A    K    Field02
R    RFILE3    PFILE(PF03)
A    K    Field01
A    K    Field02
(the three PF share the same key structure ).
Your Cobol program is able to read such an LF with SEQUENTIAL, DYNAMIC and RANDOM Access as with a normal one. Remember that COBOL/400 supplies the register variable DB-FORMAT-NAME which hosts the name of the last format read.
Let me know if it's clear enough.
Yours sincerely.

Domenico Finucci

-----Messaggio originale-----
Da: David Keck [mailto:dkeck@idt.net]
Inviato: mercoledý 24 maggio 2000 17.47
A: cobol400-l@midrange.com
Oggetto: Non-Join multi-PF logical file format

Can a COBOL program work with a non-join logical file record format which references more than one PF (more than one PF in the DDS PFILE entry) ?  I know RPG programs can NOT compile if they reference such a file.  Thanks.   

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.