COBOL

COBOL

COBOL

COBOL is responsible for the efficient, reliable, secure, and unseen day-to-day operations of the world's economy.

 View Only
  • 1.  [HELP] BATCH Dynamic File Alocation + "Recording mode is U"

    Posted Mon April 11, 2016 11:26 AM

    Hi Everyone.

    First time poster here, sorry if I'm breaking any laws.

    I'm facing the following situation and can't find any solution:

    I just need to read a file that I dynamically allocate with BPXWDYN "ALLOC DD(ORIGEM) DSN(PATH.TO.THE.FILE.ORIGEM) SHR MSG(WTP)"

    This file can either be FB or VB (I receive it as a parameter from JCL).

    I'm trying a lot of combination on my File Section using "RECORDING MODE IS U" but I getting  File Status 39 every time.

     

    Rogelin


  • 2.  Re: [HELP] BATCH Dynamic File Alocation + "Recording mode is U"

    Posted Mon April 11, 2016 11:38 AM

    Although you want to process F- or V-type datasets, you are going to need to match the RECFMs to your program. So, on your BPXWDYN, supply a RECFM of U. This will allow you to process the dataset as Undefined, no matter what it is originally.

    This would be the same if you just used a plain DD statement in the JCL. Have RECFM=U on it, and it "becomes" an Undefined-type dataset to your COBOL program.

    Just a note, when you use PATH.TO.THE.FILE.ORIGEM, it is not a "path". I make the point because it *is* possible to specify a path on a DD-statement, which takes you to HFS.

    BillWoodger


  • 3.  Re: [HELP] BATCH Dynamic File Alocation + "Recording mode is U"

    Posted Mon April 11, 2016 12:25 PM

    Thanks (Muito obrigado!) for your answer @BillWoodgertype ahead list box 

    But I'm still getting FS 39 after adding RECFM(U) to the BPXWDYN command.

    I think the problem can be on my FD but I can't find where I'm messing things.

    Here is the 3 FD versions I tried:

    V1:

           FD  ORIGEM                                                  
               RECORDING MODE IS U                                     
               RECORD CONTAINS 1 TO 32767 CHARACTERS.                  
           01  FD-ORIGEM-READ.                                         
               10 FD-ORIGEM-CHAR PIC  X(01)OCCURS 32767                                         
                  DEPENDING ON WRK-FD-LENGTH.       

    V2:

           FD  ORIGEM                                                       
               RECORDING MODE IS U                                          
               RECORD IS VARYING IN SIZE FROM 1 TO 32767 CHARACTERS         
               DEPENDING ON WRK-FD-LENGTH.                           
           01  FD-ORIGEM-READ.                                              
               10 FD-ORIGEM-CHAR PIC X(01) OCCURS 1 TO 32767 
                  DEPENDING ON WRK-FD-LENGTH. 

    V3:

           FD  ORIGEM                                                       
               RECORDING MODE IS U.                           
           01  FD-ORIGEM-READ.                                              
               10 FD-ORIGEM-CHAR PIC X(32767).

     

    Both of them are returning FS39 after READ.

     

    Rogelin


  • 4.  Re: [HELP] BATCH Dynamic File Alocation + "Recording mode is U"

    Posted Mon April 11, 2016 03:36 PM

    OK, it's not clear if you have coded FILE STATUS on the SELECT, or whether you are letting the run-time deal with it.

    You are probably getting a message with more information.

    Either way, what you also need is an LRECL. So add an LRECL of 32767, that matches the maximum size in your program.

    V1 or V2 are more convenient than V3, as you will know the length of each record.

    If you have variable-length unblocked records, the data will contain the RDW.

    If you have variable-length blocked records, you will have a BDW, and an RDW for each record, within the single "record" you read, which will be the complete block plus the BDW.

    For fixed-length records you'll just get a lump of data, all except, most often, the last, being the same size. You won't know if they are blocked or not.

    So your program will need to acquire information about the actual dataset, before the data can be correctly interpreted - depending on what you want to do.

    BillWoodger