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

VB File attribute mismatch


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 97
Location: India

PostPosted: Wed Nov 14, 2012 1:31 pm
Reply with quote

Hi,

My Cobol program has the following file definition for an input dataset -

Code:
**** THE BELOW FILE IS BEING DEFINED AS VARIABLE ALTHOUGH IT
****  IS REALLY FIXED 1635. THIS IS BECAUSE THE BACKUP FILE 
****  BEING INPUTTED IS WRITTEN AS VARIABLE.                 
****                                                     

FD  INPUT-FILE                                 
     RECORDING MODE V                           
     LABEL RECORDS OMITTED                       
     RECORD 1635 TO 32752 BLOCK 0.               
 01  DUMMY-RECORD.                               
     05  FILLER                   PIC X(32752). 


My JCL uses a GDG version for the above file.

In 3.4 the file attributes are displayed as –

Code:
  Organization  . . . : PS       
  Record format . . . : VB       
  Record length . . . : 1639     
  Block size  . . . . : 27998     
  1st extent cylinders: 100       
  Secondary cylinders : 100       
  Data set name type  :           
  SMS Compressible. . : NO 


When I try to run the JCL in test environment, it gives me input error for the file. Status-code = 39.

Code:
A file attribute mismatch was detected. File INPUT-FILE in program had a record length of 32756 and
the file specified in the ASSIGN clause had a record length of 1639.


Do you know what is causing the problem.

Thanks
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Nov 14, 2012 1:49 pm
Reply with quote

Why is the record in the FD defined like that if your maximum/only length is 1635 of data?
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 97
Location: India

PostPosted: Wed Nov 14, 2012 2:42 pm
Reply with quote

Hi Bill,

The VB file may contain records more than 1635 of length & hence FD is defined such as to let COBOL run as is even for increase in length.

Thanks
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Nov 14, 2012 5:15 pm
Reply with quote

Learncoholic, the error message is EXTREMELY explicit about what your problem is. The error message states that your program has defined the file as having records with LRECL 32756 yet the physical file has LRECL 1639. What do you not understand about that error message?

The system is telling you that your belief the file has record length 32752 is wrong -- believe the system and change your program. And, by the way, the VB file may NOT contain records more than 1635 bytes long -- your system indicates that the file is not spanned, and the LRECL is 1639 so the longest any record will EVER be is 1635 bytes.
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 97
Location: India

PostPosted: Wed Nov 14, 2012 5:42 pm
Reply with quote

Thanks Robert.

The problem to me is more than intended in the error message.
When the COBOL is executed in production, the INPUT file is opened successfully & the module is executing as it is.

But when the same program is run in Test, it's abending with the error message.

So I am un-ceratin about how the same program is executing fine in production but throwing the error in test.

Is there a problem with compilation parms?

Thanks
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Nov 14, 2012 5:48 pm
Reply with quote

If it is working in Production, check the characteristics of the dataset in Production and let us know.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Nov 14, 2012 5:52 pm
Reply with quote

Obviously, the program running in production and the program running in test are not the same program if the same input file (and you ARE using the same input file -- not a copy, right?) in the two programs generated different results. Why the difference? It may be how the program was compiled, it may be test and production files are not the same, it may be pretty much anything. Your job, as a programmer, is to figure out what the difference is.

But you STILL need to understand that your belief that the file will contain any records longer than 1635 bytes is not rational and definitely not supported by what the system is telling you. Unless your application creates records by combining data in multiple input records from the file, there simply is no way for you to ever have a record longer than 1635 bytes -- PERIOD.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Wed Nov 14, 2012 7:32 pm
Reply with quote

Learncoholic wrote:
In 3.4 the file attributes are displayed as –

Code:
  Organization  . . . : PS       
  Record format . . . : VB       
  Record length . . . : 1639     
  Block size  . . . . : 27998     
  1st extent cylinders: 100       
  Secondary cylinders : 100       
  Data set name type  :           
  SMS Compressible. . : NO 
For a check, look at the attributes of the file being used in Production for this program and verify with above information.
Back to top
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico

PostPosted: Wed Nov 14, 2012 7:57 pm
Reply with quote

Good morning to all!

If you are saying that the program and the file attributes in the PRODUCTION system are the same as in the TEST system then I don't know how it's running in the production system. In your FD you are not including the four bytes for the record length for every record on the file,
S/B RECORD 1639 TO 32756. Plus you need to add a 01 for the smallest record on the file, in this case it be 1639.
S/B 01 DUMMY-SM-RECORD.
05 FILLER PIC X(1639).

01 DUMMY-RECORD.
05 FILLER PIC X(32756).
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Nov 14, 2012 10:13 pm
Reply with quote

Jose,

I've never had to define the RDW in a Cobol FD.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Nov 14, 2012 11:01 pm
Reply with quote

Jose, the Enterprise COBOL Programming Guide manual specifically states in 1.9.1.1.3 that what you posted is not right (emphasis added):
Quote:
Format-V QSAM records have control fields that precede the data. The QSAM logical record length is determined by adding 4 bytes (for the control fields) to the record length defined in your program, but you must not include these 4 bytes in the description of the record and record length.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Nov 15, 2012 1:08 am
Reply with quote

The following previous post might be beneficial -

www.ibmmainframes.com/viewtopic.php?p=293539&highlight=#293539
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 97
Location: India

PostPosted: Wed Nov 21, 2012 8:47 pm
Reply with quote

Thanks to all.

I resolved the situation to find that the problem was not in COBOL at all.

Actually the I/P file I was referring to was a version of GDG.
Now, 2 different programs creates 2 different versions of the same GDG.
Each of the programs uses different LRECL for their respective versions.

The Program that I referred to as abending uses the latest version of the GDG. This version has LRECL of 1639.

After this program was executed in production, another program created a new version of the GDG with different LRECL.

Since the program (that I referred to) uses the latest version of the GDG in production, so in test we executed the module with latest version of GDG. However we were oblivious of the fact that a GDG version was created with diff LRECL after the module was executed.
This resulted in the confusion.

Thanks once again for taking time out to look into my problem.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Wed Nov 21, 2012 10:22 pm
Reply with quote

Hello,

Quote:
After this program was executed in production, another program created a new version of the GDG with
Why is this even tolerated . . . icon_sad.gif

Any processing that creates a new Generation (NOT version) should use a common set of dcb information. . .
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 97
Location: India

PostPosted: Thu Nov 22, 2012 12:03 pm
Reply with quote

I agree with you Dick.

In case files under same GDG is created, all versions should have the same DCB.

But in actual ground this was not being followed. I am uncertain why it was set up like that.

Thanks
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK

PostPosted: Thu Nov 22, 2012 6:51 pm
Reply with quote

I assume that you are NOT talking about versions (where the Vxx bit changes) but generations (where the Gxxxx bit changes)?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Fri Nov 23, 2012 8:54 am
Reply with quote

Hello,

I'm more than 99% sure that these are Generations NOT Versions.

Poor design is why/how this was set up this way. I'd encourage doing the research and determine how to hace one set of dcb info.
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 -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Unable to interpret a hex value to De... COBOL Programming 4
No new posts how to eliminate null indicator value... DB2 7
No new posts Format Binary file to EBCDIC JCL & VSAM 4
No new posts Binary File format getting change whi... All Other Mainframe Topics 7
No new posts Compare 2 files and retrive records f... DFSORT/ICETOOL 3
Search our Forums:

Back to Top