IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Reading sam files where record length is undefined


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
cat24

New User


Joined: 15 Jul 2005
Posts: 3

PostPosted: Fri Jul 15, 2005 10:17 pm
Reply with quote

Hello all,

I'm writing a little program to read a SAM fixed length file and determine if it is empty, if so its sets a return code and closes and opens the file output and writes a message into the empty file indicating 'no activity'.

This works fine, however I am trying to make this work for any fixed record length. My attemps usually end in a compile error or a return code 39 which indicates a DCB mis-match.

Is there any way in COBOL to read a fixed length file/record using a parm passed from the JCL for record length?

Mike
Back to top
View user's profile Send private message
die7nadal

Active User


Joined: 23 Mar 2005
Posts: 156

PostPosted: Sun Jul 17, 2005 11:10 am
Reply with quote

I assume that u wud have resolved this issue, if not this can be accomplished in COBOL program by calling IDCAMS and by issuing the PRINT COMMAND to check if the file is empty. The Dataset which has to be checked for emptiness can be given as an Instream Data. If you are interested I can give you the COBOL code.
Back to top
View user's profile Send private message
cat24

New User


Joined: 15 Jul 2005
Posts: 3

PostPosted: Sun Jul 17, 2005 5:32 pm
Reply with quote

Hi die7nadal,

Our current solution uses the IDCAMs utility in JCL, and step conditioning, however in our experience IDCAMs cannot read a GDG, thus we copy large files from GDG virtual tape and virtual disk to QSAM and use IDCAMs print and respond to the condition code 4, the COBOL solution was to simplify this and cut processing time and I/O, especially the copies from GDG.

The program which works for a fixed 133 bytes (FBA) and
any fixed blocksize at the moment reads as follows, it runs in .01 CPU sec which is highly desirable due to applications volume:

100-MAIN.

OPEN INPUT FILE-IN.

READ FILE-IN
..AT END
..MOVE 04 TO RETURN-CODE
..CLOSE FILE-IN
..OPEN FILE-IN OUPUT
..MOVE <message> TO FILE-IN 01 level
..WRITE FILE-IN 01 level back to source .

CLOSE FILE-IN.
GOBACK.

I was unable to get this to work opening the file I-O.

The DISP in JCL is (MOD, KEEP, KEEP)

File types being checked are all fixed length QSAM. virtual tape and disk, 3480 physical tape, and GDG based virtual tape and disk and 3480 physical tape.

The blocksizes vary and are not an issue.

I have not tried calling IDCAMs from COBOL, I was not aware it was an option. I would appreciate the code if you have the time. But the original issue was IDCAMs was unable to read GDG.

Thanks in advance,

Mike
Back to top
View user's profile Send private message
die7nadal

Active User


Joined: 23 Mar 2005
Posts: 156

PostPosted: Sun Jul 17, 2005 9:45 pm
Reply with quote

Mike,
I am still not able to get why you are not able to read a GDG in IDCAMS. If you specify the GDG in the INSTREAM data u wont be able to access a Generation Data Set, like here

Code:
PRINT INDATASET(GDG.#1(+0)) COUNT(1)


But if u mention the GDG in a DD name you will be able to do so like here
Code:

//TEST   JOB CRIS00M0,'DIE7NADAL',MSGCLASS=T,NOTIFY=&SYSUID,
//       MSGLEVEL=(1,1)                                   
//*MAIN SYSTEM=SYBO,CLASS=MISCBAT                         
//COUNT    EXEC PGM=IDCAMS                               
//SYSPRINT DD SYSOUT=*                                   
//IN       DD DSN=GDG.#1(+0),DISP=SHR             
//SYSIN    DD *                                           
    PRINT INFILE (IN) COUNT(1)                           
//*                                                       


Here GDG.#1(0) would be your VIRTUAL TAPE GDG

As of COBOL I assumed that this operation had to be performed inbetween some sort of complex processing thats why I chose COBOL. But if your processing allows this to perform in JCL that wud be great and more effecient than COBOL.

The COBOL code that I have mentioned below cannot process the GDG bcos the DS is mentioned as an INSTREAM data, so this is just to show you how to call IDCAMS from a COBOL pgm. So if you are still interested in the COBOL here it goes,
Code:

* CALLING IDCAMS FROM A COBOL PROGRAM                         
* WHILE COMPILNG THIS PROGRAM USE DATA(24) AMODE(24) RMODE(24)
* IDCAMS MODULE SHOULD ONLY BE CALLED DYNAMICALLY                 
* PGM TO CHECK IF AN INPUT FILE IS EMPTY REGARDLESS OF THE   
* RECFM AND THE LRECL.                                       
 IDENTIFICATION DIVISION.                                     
 PROGRAM-ID. ICAMS1.                                         
 AUTHOR. DIE7NADAL.                                               
                                                             
 ENVIRONMENT DIVISION.                                       
 INPUT-OUTPUT SECTION.                                       
 FILE-CONTROL.                                               
     SELECT IDCAMS-PARMS ASSIGN TO CAMSPARM                   
           FILE STATUS IS CAMSPARM-STATUS.                   
                                                             
 DATA DIVISION.                                               
 FILE SECTION.                                               
 FD IDCAMS-PARMS                       
     RECORDING MODE IS F               
     BLOCK CONTAINS 0 RECORDS.         
 01 IDCAMS-BUFFER          PIC X(80). 
                                       
 WORKING-STORAGE SECTION.             
 01 CAMSPARM-STATUS        PIC X(02). 
    88  CAMS-PARMFILE-OK   VALUE ZEROS.
 01 PARM-OPTIONS.                                       
    05 PO-LENGTH          PIC S9(4) BINARY VALUE +0.   
    05 PARM-OPTS          PIC X(04).                   
 01 DDNAME-OPTIONS.                                     
    05 DO-LENGTH          PIC S9(4) BINARY VALUE +48.   
    05                    PIC X(32) VALUE LOW-VALUES.   
    05 SYSIN-DD           PIC X(08) VALUE 'CAMSPARM'.   
    05 SYSPRINT-DD        PIC X(08) VALUE 'SYSOUT'.     
                                                       
* CALL IDCAMS                                           
 PROCEDURE DIVISION.                                   
     OPEN OUTPUT IDCAMS-PARMS.         
     ACCEPT IDCAMS-BUFFER FROM SYSIN   
     WRITE IDCAMS-BUFFER               
     DISPLAY IDCAMS-BUFFER             
     CLOSE IDCAMS-PARMS                 
     CALL 'IDCAMS' USING PARM-OPTIONS   
                         DDNAME-OPTIONS
     IF RETURN-CODE = ZEROS             
        DISPLAY 'FILE IS NOT EMPTY '   
     ELSE IF RETURN-CODE = 4           
        DISPLAY 'FILE IS EMPTY '       
     ELSE                               
        DISPLAY ' ABEND '.             
     STOP RUN.                         


The RunJCL,
Code:

//ICAMS1 JOB (CRIS00M0),'DIE7NADAL',MSGCLASS=T,REGION=0K,
//    NOTIFY=&SYSUID                                   
//STEP01    EXEC PGM=ICAMS1                           
//STEPLIB  DD DSN=LOADLIB,DISP=SHR   
//SYSOUT   DD SYSOUT=*                                 
//CAMSPARM DD DSN=&&TEMP,                             
//           DCB=(RECFM=FB,LRECL=80)                   
//SYSIN    DD *                                       
  PRINT INDATASET(TEST.#1) COUNT(1)
/*                                         
Back to top
View user's profile Send private message
cat24

New User


Joined: 15 Jul 2005
Posts: 3

PostPosted: Mon Jul 18, 2005 7:14 am
Reply with quote

Actually it's been so long since the IDCAMs reading the GDG issue I don't remember what the error was.

Determining the file is empty is one issue, the other is writing back the 'no activity' message to make it not empty.

The reason for this excersise is to do after the fact processing, on dozens of output print and data files that are currently sent to fiche and tape. But will now be sent to CD and FTP'ed. The base applications programs cannot be modified, but the output datsets can before they are IEBGENERed to the CD queue or FTP server.

I'm back in the office on Wednesday, and will look further into this. The idea was to have a one step solution to fix an empty file. JCL/Utility solutions require multi-step processing, with step conditioning, and we have dozens of jobs to change, the one step solution seems a far simpler, and easier to test solution.

Mike
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts How to split large record length file... DFSORT/ICETOOL 10
No new posts PARSE Syntax for not fix length word ... JCL & VSAM 7
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts Write line by line from two files DFSORT/ICETOOL 7
No new posts FINDREP - Only first record from give... DFSORT/ICETOOL 3
Search our Forums:

Back to Top