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?
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.
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:
OPEN INPUT FILE-IN.
..MOVE 04 TO RETURN-CODE
..OPEN FILE-IN OUPUT
..MOVE <message> TO FILE-IN 01 level
..WRITE FILE-IN 01 level back to source .
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.
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,
* 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.
SELECT IDCAMS-PARMS ASSIGN TO CAMSPARM
FILE STATUS IS CAMSPARM-STATUS.
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS.
01 IDCAMS-BUFFER PIC X(80).
01 CAMSPARM-STATUS PIC X(02).
88 CAMS-PARMFILE-OK VALUE ZEROS.
05 PO-LENGTH PIC S9(4) BINARY VALUE +0.
05 PARM-OPTS PIC X(04).
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
OPEN OUTPUT IDCAMS-PARMS.
ACCEPT IDCAMS-BUFFER FROM SYSIN
CALL 'IDCAMS' USING PARM-OPTIONS
IF RETURN-CODE = ZEROS
DISPLAY 'FILE IS NOT EMPTY '
ELSE IF RETURN-CODE = 4
DISPLAY 'FILE IS EMPTY '
DISPLAY ' ABEND '.
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.