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:
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.
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.
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).
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=*
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.
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)
