|
View previous topic :: View next topic
|
| Author |
Message |
I?aki Viggers
New User
Joined: 18 Jun 2005
Posts: 13
|
|
|
|
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 |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2272
Location: USA
|
|
|
|
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… 
P.S.
When posting your code, do not forget to use the Code button, to make it visible to readers. |
|
| Back to top |
|
|
I?aki Viggers
New User
Joined: 18 Jun 2005
Posts: 13
|
|
|
|
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 |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2272
Location: USA
|
|
|
|
| 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!
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 |
|
|
I?aki Viggers
New User
Joined: 18 Jun 2005
Posts: 13
|
|
|
|
| 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 |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2272
Location: USA
|
|
|
|
| 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 |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
