|
View previous topic :: View next topic
|
| Author |
Message |
Paul1983
New User
Joined: 08 Jul 2008
Posts: 37
Location: bangy
|
|
|
|
Hi,
Could you please let me know whether it is possible to rewrite a variable length file? I'm getting a FILE STATUS 39.
Thanks,
Paul |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Yes, it is possible to rewrite a variable length file.
I thought 39 file status meant the OPEN failed, not the REWRITE. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| as Robert indicated, your file-status error had nothing to do with the REWRITE instruction. Your DCB parms in JCL did not match your FD Select and File definitions. |
|
| Back to top |
|
|
Paul1983
New User
Joined: 08 Jul 2008
Posts: 37
Location: bangy
|
|
|
|
i want to rewrite the input file itself.So there is no DCB parms involved
Thanks,
Paul |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Paul1983 wrote: |
| i want to rewrite the input file itself.So there is no DCB parms involved |
Locate your file via ISPF 3.4, check for the RECFM there in Data Set Information, then check whether it is in sync with the FD entries of this file in your program.. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Paul: who said anything about DCB parms -- besides, VSAM files use ACB parms not DCB parms? If the OPEN fails, the REWRITE isn't going to work no matter what you do. File status 39 means something doesn't match between your COBOL file definition and the actual physical file. For example: your COBOL program may have variable length records in the FD but the VSAM file is defined with RECORDSIZE (X X) which means it is NOT variable length. This could cause a 39 file status. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Here, maybe this is easier to understand:
Your FD Select and File definitions do not match physical attributes of your 'existing file'.
To quote from our own Sherlock Holmes:
there is a difference between persistant and thick-headed. |
|
| Back to top |
|
|
Paul1983
New User
Joined: 08 Jul 2008
Posts: 37
Location: bangy
|
|
|
|
My file attributes are as follows
Record format . . . : VB
Record length . . . : 23472
Block size . . . . : 23476
in the FD section i declared it as
FD POL-CURR
BLOCK 0
RECORDING V
LABEL RECORDS STANDARD.
01 POL-CURR-REC PIC X(23472).
Is this correct?
Thanks,
Paul |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Hi,
Syntactically it looks correct, probably we are missing something which is not posted yet. Please post the SYSOUT of failed JOB & all the FD entries from your program (unless there are a lots of files).
Please use BBcode when posting SYSOUT & FD. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
01 POL-CURR-REC PIC X(23472).
I think this should be:
01 POL-CURR-REC PIC X(23468). |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Experiment with the following -
| Code: |
FD POL-CURR
BLOCK 0
RECORDING V
RECORD CONTAINS XXXXX TO 23472 CHARACTERS
DEPENDING ON WS-IN-LGTH
LABEL RECORDS STANDARD.
01 POL-CURR-REC PIC X(23472).
WORKING-STORAGE SECTION.
03 WS-IN-LGTH PIC 9(08) BINARY.
|
Change the XXXXX to the minimum record length with 23472 being the maximum.
After a READ, field WS-IN-LGTH will contain the actual length of the record just read. Note that this field's picture clause must be unsigned, with my preference being a binary-fullword, but display-numeric and packed-decimal can also be used.
If you are writing the record to another file, the same applies. Substitute with a field named WS-OUT-LGTH and populate this field with the actual record-length prior to the WRITE.
Note that this was introduced with COBOL2 4.0, many years ago.
HTH....
Bill |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
From the LR manual:
| Quote: |
6.2.31.4 Sequential files
For files in the sequential access mode, the last prior input/output statement executed for this file must be a successfully executed READ statement. When the REWRITE statement is executed, the record retrieved by that READ statement is logically replaced.
The number of character positions in record-name-1 must equal the number of character positions in the record being replaced.
The INVALID KEY phrase must not be specified for a file with sequential organization. An EXCEPTION/ERROR procedure can be specified. |
Paul, if you're dealing with a sequential file REWRITE, as the manual quote indicates you cannot change the record length in the REWRITE. |
|
| Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007
Posts: 1399
Location: IL, USA
|
|
|
|
Yes Dick Brenholtz is right.
for VB FILE 4 bytes are used for RDW
I tried your code its runing fine here... |
|
| Back to top |
|
|
Paul1983
New User
Joined: 08 Jul 2008
Posts: 37
Location: bangy
|
|
|
|
mine is a KSDS file.So the organization in the SELECT statement should be given as INDEXED with ACCESS MODE as sequential since
I need to update the header record of ths file. |
|
| Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007
Posts: 1399
Location: IL, USA
|
|
|
|
have you tried giving IDCAMS --> VERIFY.
file may be already open.. |
|
| Back to top |
|
|
|
|
