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

IKJACCNT and WRNG.LEN.RECORD


IBM Mainframe Forums -> ABENDS & Debugging
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
I?aki Viggers

New User


Joined: 18 Jun 2005
Posts: 8

PostPosted: Wed Jun 22, 2022 2:29 am
Reply with quote

I'm experiencing the following issue in Hercules/TK4.

I made a simple COBOL program that creates a new file, writes into it just one record, and closes the file. The job runs successfully (RC=0000) and the file is actually created. The problem is that from then on, any attempt to view/edit the COBOL code or the JCL code leads to the message:

Code:
HERC01  ,IKJACCNT,241,DA,SYS00064,READ  ,WRNG.LEN.RECORD,00000006001515,BSAM


What do I need to do in order to recover the ability to edit the COBOL and/or JCL code?

I see no indication in the JES2 Job Log of what might be causing this problem. Let me know if I should copy/paste the entire log or just specific portions.
Back to top
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 1533

PostPosted: Wed Jun 22, 2022 3:04 am
Reply with quote

1) bring here your JCL code, in full

2) bring here your COBOL code, in full

3) this may happen if your code is trying to write data into itself, instead of a separate dataset supposed to store your output data. This is the same as a snake biting its own tail. The result is the same: immediate death… 824.gif

P.S.
When posting your code, do not forget to use the Code button, to make it visible to readers.
Back to top
View user's profile Send private message
I?aki Viggers

New User


Joined: 18 Jun 2005
Posts: 8

PostPosted: Wed Jun 22, 2022 3:12 am
Reply with quote

Thank you for looking in to this.

1) JCL:
Code:
000001 //JOB2 JOB (COBOL),'TST',CLASS=A,MSGCLASS=H,                   
000002 //  NOTIFY=HERC01,MSGLEVEL=(1,1)                               
000003 //EXCT EXEC COBUCG                                             
000004 //COB.SYSPUNCH DD DUMMY                                       
000005 //COB.SYSIN DD DSN=HERC01.YOUTUBE.MOSHIX(IVCBL2),DISP=SHR     
000006 //COB.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                   
000007 //GO.SYSOUT DD SYSOUT=*                                       
000008 //GO.FILE1 DD DSN=HERC01.YOUTUBE.MOSHIX(FILE1),DISP=SHR,       
000009 //  DCB=(RECFM=FBA,LRECL=5,BLKSIZE=16100)                     
000010 //                                                             


2) COBOL:
Code:
00001          IDENTIFICATION DIVISION.                 
00002          PROGRAM-ID. 'IVCBL2'.                     
00003          ENVIRONMENT DIVISION.                     
00004          INPUT-OUTPUT SECTION.                     
00005          FILE-CONTROL.                             
00006              SELECT FHANDL ASSIGN TO UT-S-FILE1   
00007                ACCESS MODE IS SEQUENTIAL.         
00008          DATA DIVISION.                           
00009          FILE SECTION.                             
00010          FD  FHANDL LABEL RECORDS ARE OMITTED.     
00011          01  RECOR.                               
00012          05  FIELD1 PIC X(5).                     
00013          PROCEDURE DIVISION.                       
00014              MOVE 'ASDFG' TO FIELD1.               
00015              OPEN OUTPUT FHANDL.                   
00016              WRITE RECOR.                         
00017              CLOSE FHANDL.                         
00018              STOP RUN.                             


3) From the COBOL source code it doesn't appear that I'm writing data into itself. But even if I did, it's odd that the "punished" files, so to speak, are the COBOL & JCL codes rather than the output file (more so with RC=0000).
Back to top
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 1533

PostPosted: Wed Jun 22, 2022 3:55 am
Reply with quote

I?aki Viggers wrote:
Thank you for looking in to this.

1) JCL:
Code:
000001 //JOB2 JOB (COBOL),'TST',CLASS=A,MSGCLASS=H,                   
000002 //  NOTIFY=HERC01,MSGLEVEL=(1,1)                               
000003 //EXCT EXEC COBUCG                                             
000004 //COB.SYSPUNCH DD DUMMY                                       
000005 //COB.SYSIN DD DSN=HERC01.YOUTUBE.MOSHIX(IVCBL2),DISP=SHR     
000006 //COB.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                   
000007 //GO.SYSOUT DD SYSOUT=*                                       
000008 //GO.FILE1 DD DSN=HERC01.YOUTUBE.MOSHIX(FILE1),DISP=SHR,       
000009 //  DCB=(RECFM=FBA,LRECL=5,BLKSIZE=16100)                     
000010 //                                                             


2) COBOL:
Code:
00001          IDENTIFICATION DIVISION.                 
00002          PROGRAM-ID. 'IVCBL2'.                     
00003          ENVIRONMENT DIVISION.                     
00004          INPUT-OUTPUT SECTION.                     
00005          FILE-CONTROL.                             
00006              SELECT FHANDL ASSIGN TO UT-S-FILE1   
00007                ACCESS MODE IS SEQUENTIAL.         
00008          DATA DIVISION.                           
00009          FILE SECTION.                             
00010          FD  FHANDL LABEL RECORDS ARE OMITTED.     
00011          01  RECOR.                               
00012          05  FIELD1 PIC X(5).                     
00013          PROCEDURE DIVISION.                       
00014              MOVE 'ASDFG' TO FIELD1.               
00015              OPEN OUTPUT FHANDL.                   
00016              WRITE RECOR.                         
00017              CLOSE FHANDL.                         
00018              STOP RUN.                             


3) From the COBOL source code it doesn't appear that I'm writing data into itself. But even if I did, it's odd that the "punished" files, so to speak, are the COBOL & JCL codes rather than the output file (more so with RC=0000).


From your JCL it's getting obvious that you are writing your output data (//GO.FILE1 DD) into the same library dataset (DSN=HERC01.YOUTUBE.MOSHIX), with a new member name (FILE1). Your COBOL code is "successfully" changing the dataset attributes LRECL=, and BLKSIZE= to those prepared for your output FILE1 of your COBOL code.

Starting this moment your original library DSN=HERC01.YOUTUBE.MOSHIX becomes unusable for maintaining neither JCL code, nor COBOL code. The message "WRNG.REC.LEN" means "wrong record length"; it proves that you destroyed the original value of LRECL=80 to new value LRECL=5 as shown in your //FILE1 DD. You can analyze it in DSN attributes, using ISPF menus, or any other utility functions.

This is exactly what I suspected before seeing your real code: you've created the real snake biting its own tail!

icon_pray.gif

You also need to stop using the term "file" in place of "dataset". Any attempt to do so leads inevitably to the full misunderstanding of: what is really happening?

Hint: for debugging purpose start from //GO.FILE1 DD SYSOUT=*
Back to top
View user's profile Send private message
I?aki Viggers

New User


Joined: 18 Jun 2005
Posts: 8

PostPosted: Wed Jun 22, 2022 6:14 am
Reply with quote

Quote:
This is exactly what I suspected before seeing your real code

Nice insight. Thanks to your feedback, I managed to solve this issue by sending the output to another dataset (this time making sure that I don't override this dataset's parameters).

Before following that approach, I tried setting (in the JCL) LRECL and BLKSIZE to the same values with which I created the library dataset HERC01.YOUTUBE.MOSHIX, but that was still messing up this library. Why is that? I would think that being consistent with the library's LRECL and BLKSIZE parameters would be enough to prevent that issue from happening.
Back to top
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 1533

PostPosted: Wed Jun 22, 2022 8:13 am
Reply with quote

I?aki Viggers wrote:
Before following that approach, I tried setting (in the JCL) LRECL and BLKSIZE to the same values with which I created the library dataset HERC01.YOUTUBE.MOSHIX, but that was still messing up this library. Why is that? I would think that being consistent with the library's LRECL and BLKSIZE parameters would be enough to prevent that issue from happening.

I recommend you to try investigating this issue yourself. Otherwise this endless series of questions "how to calculate 2+2?", then "how to calculate 2+3?", etc. would never end.

Try creating your NEW dataset for //FILE1 DD DISP=(NEW,CATLG),..., but do not specify neither of DCB parameters in this DD. Then analyze: what are the attributes of your new dataset built from your COBOL code?

Hint: the attributes of any output dataset in zOS are chosen from three places, by priorities:

#1 - the explicit or implicit attributes generated by the running program itself (in fact, those ones placed into the internal data control block, DCB). COBOL program behavior may be unexpected; it can also take into account the available DCB parameters from DD statement, or not...
#2 - those attributes not defined yet are taken from actual DCB parameters in the corresponding DD statement
#3 - finally, those attributes still not defined are taken from the dataset control block (DSCB - equivalent to the dataset label) - only if the used dataset has been created earlier (e.g. DISP=OLD or SHR)
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 -> ABENDS & Debugging

 


Similar Topics
Topic Forum Replies
No new posts Adding a trailer with record count an... JCL & VSAM 4
No new posts Splitting group records based on deta... DFSORT/ICETOOL 8
No new posts ICE218A 6 12 BYTE VARIABLE RECORD IS ... DFSORT/ICETOOL 14
No new posts ICETOOL with JOINKEY for Big record l... DFSORT/ICETOOL 12
No new posts Finding record and replacing with val... DFSORT/ICETOOL 3
Search our Forums:

Back to Top