COBOL for MVS - var lenght files 
Author Message
 COBOL for MVS - var lenght files

I have an OS/VS COBOL program that has been converted to COBOL for MVS.
The program reads a variable length VSAM file.  There are thousands of
these files, anyone of which may be dynamically allocated to the
program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
files.  
My problem - OS/VS COBOL did not require that the maximum length of a
file exactly match the file description within the program.  COBOL for
MVS requires that they match.  The program is taking an error on the
open statement with a file status of 39.  It also puts the follwing
message to sysout:

IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
CART10 had a record length of 27000 and the file specified in the ASSIGN
clause had a record length of 22514.  It does not open the file.

Is there any way to get COBOL/MVS to handle this???  

The open statement is generating a call to the COBOL run time IGZEVOP.

Any info would be appreciated.

--



Mon, 24 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files


Quote:
>I have an OS/VS COBOL program that has been converted to COBOL for MVS.
>The program reads a variable length VSAM file.  There are thousands of
>these files, anyone of which may be dynamically allocated to the
>program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
>files.
>My problem - OS/VS COBOL did not require that the maximum length of a
>file exactly match the file description within the program.  COBOL for
>MVS requires that they match.  The program is taking an error on the
>open statement with a file status of 39.  It also puts the follwing
>message to sysout:

>IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
>CART10 had a record length of 27000 and the file specified in the ASSIGN
>clause had a record length of 22514.  It does not open the file.

>Is there any way to get COBOL/MVS to handle this???  >
>The open statement is generating a call to the COBOL run time IGZEVOP.

>Any info would be appreciated.

>--

There is a pretty ugly work-around (not solution) which is to use the CMPR2
compiler option.  This should end the FS=39, but it also means that you
can't use any new '85 features or Intrinsic Functions.

Does the maximum length in your program really match the largest size from
your IDCAMS?   I thought that you could put a larger value in the FD and
avoid the FS=39, but I could be completely wrong on that. (I I know that you
get the error with an FD that is smaller than  the IDCAMS).

P.S.  Do any of the VSAM files that you work with have alternate indexes?
If so, you may run into another OS/VS COBOL vs COBOL for MVS issue.  You may
have problems with programs that use a file defined with an alternate index
via IDCAMS but not declared to have one in the COBOL source.  Just a
warning, in case this turns out to be another problem.



Mon, 24 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

On Thu, 05 Feb 1998 15:13:30 -0500, Jim Ferguson <"Jim Ferguson">

Quote:
>I have an OS/VS COBOL program that has been converted to COBOL for MVS.
>The program reads a variable length VSAM file.  There are thousands of
>these files, anyone of which may be dynamically allocated to the
>program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
>files.  
>My problem - OS/VS COBOL did not require that the maximum length of a
>file exactly match the file description within the program.  COBOL for
>MVS requires that they match.  The program is taking an error on the
>open statement with a file status of 39.  It also puts the follwing
>message to sysout:

>IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
>CART10 had a record length of 27000 and the file specified in the ASSIGN
>clause had a record length of 22514.  It does not open the file.

>Is there any way to get COBOL/MVS to handle this???  

>The open statement is generating a call to the COBOL run time IGZEVOP.

>Any info would be appreciated.

I think you can get around this by coding a second record definition
with the maximum length of 27000

01  INPUT-RECORD-MAX-LENGTH                              PIC X(27000).
01  INPUT-RECORD REDEFINES INPUT-RECORD-MAX-LENGTH
      COPY XXXXXXX

I ran into this a long time ago and I believe that at least one of the
record definitions for a var length record has to equal that coded in
the JCL (minus 4 bytes).



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Quote:


> >I have an OS/VS COBOL program that has been converted to COBOL for MVS.
> >The program reads a variable length VSAM file.  There are thousands of
> >these files, anyone of which may be dynamically allocated to the
> >program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
> >files.
> >My problem - OS/VS COBOL did not require that the maximum length of a
> >file exactly match the file description within the program.  COBOL for
> >MVS requires that they match.  The program is taking an error on the
> >open statement with a file status of 39.  It also puts the follwing
> >message to sysout:

> >IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
> >CART10 had a record length of 27000 and the file specified in the ASSIGN
> >clause had a record length of 22514.  It does not open the file.

> >Is there any way to get COBOL/MVS to handle this???  >
> >The open statement is generating a call to the COBOL run time IGZEVOP.

> >Any info would be appreciated.

> >--

> There is a pretty ugly work-around (not solution) which is to use the CMPR2
> compiler option.  This should end the FS=39, but it also means that you
> can't use any new '85 features or Intrinsic Functions.

> Does the maximum length in your program really match the largest size from
> your IDCAMS?   I thought that you could put a larger value in the FD and
> avoid the FS=39, but I could be completely wrong on that. (I I know that you
> get the error with an FD that is smaller than  the IDCAMS).

> P.S.  Do any of the VSAM files that you work with have alternate indexes?
> If so, you may run into another OS/VS COBOL vs COBOL for MVS issue.  You may
> have problems with programs that use a file defined with an alternate index
> via IDCAMS but not declared to have one in the COBOL source.  Just a
> warning, in case this turns out to be another problem.

--
The program dynamically allocates the particular VSAM file that it
needs.
The MAX recordsize varies between files.  When the largest 01 level in
the FD is larger than the MAX on the VSAM file, I get the FS=39 on the
open.  When the 01 level in the FD is smaller that the MAX parm on the
VSAM file, The open statement works but when I read a record that is
bigger than the largest 01 level in the FD, I get an FS=92, VSAM code of
x'2C' - record exceeded buffer size.  I tried the CMPR2 option, still
got the same results.  This restriction was in place under COBOL II
also.

Do you know how to get the address of the files ACB from a COBOL
program?



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files


Quote:




Quote:
>> >I have an OS/VS COBOL program that has been converted to COBOL for MVS.
>> >The program reads a variable length VSAM file.  There are thousands of
>> >these files, anyone of which may be dynamically allocated to the
>> >program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
>> >files.
>> >My problem - OS/VS COBOL did not require that the maximum length of a
>> >file exactly match the file description within the program.  COBOL for
>> >MVS requires that they match.  The program is taking an error on the
>> >open statement with a file status of 39.  It also puts the follwing
>> >message to sysout:

>> >IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
>> >CART10 had a record length of 27000 and the file specified in the ASSIGN
>> >clause had a record length of 22514.  It does not open the file.

>> >Is there any way to get COBOL/MVS to handle this???  >

>> >The open statement is generating a call to the COBOL run time IGZEVOP.

>> >Any info would be appreciated.

>> >--

>> There is a pretty ugly work-around (not solution) which is to use the
CMPR2
>> compiler option.  This should end the FS=39, but it also means that you
>> can't use any new '85 features or Intrinsic Functions.

>> Does the maximum length in your program really match the largest size
from
>> your IDCAMS?   I thought that you could put a larger value in the FD and

>> avoid the FS=39, but I could be completely wrong on that. (I I know that
you
>> get the error with an FD that is smaller than  the IDCAMS).

>> P.S.  Do any of the VSAM files that you work with have alternate indexes?
>> If so, you may run into another OS/VS COBOL vs COBOL for MVS issue.  You
may
>> have problems with programs that use a file defined with an alternate
index
>> via IDCAMS but not declared to have one in the COBOL source.  Just a
>> warning, in case this turns out to be another problem.

>--
>The program dynamically allocates the particular VSAM file that it
>needs.
>The MAX recordsize varies between files.  When the largest 01 level in
>the FD is larger than the MAX on the VSAM file, I get the FS=39 on the
>open.  When the 01 level in the FD is smaller that the MAX parm on the
>VSAM file, The open statement works but when I read a record that is
>bigger than the largest 01 level in the FD, I get an FS=92, VSAM code of
>x'2C' - record exceeded buffer size.  I tried the CMPR2 option, still
>got the same results.  This restriction was in place under COBOL II
>also.

>Do you know how to get the address of the files ACB from a COBOL
>program?

A couple of things (and mostly it sounds like you are close to needing
Assembler subroutines).

!) You absolutely can not (legaly) get the ACB address from any current
COBOL.  You can get at an FCB fro QSAM (by doing a CALL USING file-name) -
but IBM firmly rejected adding this facility for VSAM.

2) What you might try (and I don't know if this will work or not) is

Change your FD to a RECORD VAYING IN SIZE FROM 1 TO
your-very-largest-vsam-record-size DEPENDING ON working-storage-numeric-item
(new format of RECORD contains-syntax with '85 Standard COBOL).

Then make the 01 under your FD something like

    01  My-File.
          05  How-Many-bytes
                    OCCURS 1 TO your-very-largest-vsam-record-size
                    DEPENDING ON working-storage-numeric-item.
            10  Each-byte-of-record   Pic X.

As I say, I am not positive that this will work, but I think it might.



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Quote:

> >--
> > .
> > .
> >Do you know how to get the address of the files ACB from a COBOL
> >program?


> A couple of things (and mostly it sounds like you are close to needing
> Assembler subroutines).

> !) You absolutely can not (legaly) get the ACB address from any current
> COBOL.  You can get at an FCB fro QSAM (by doing a CALL USING file-name) -
> but IBM firmly rejected adding this facility for VSAM.

> 2) What you might try (and I don't know if this will work or not) is

> Change your FD to a RECORD VAYING IN SIZE FROM 1 TO
> your-very-largest-vsam-record-size DEPENDING ON working-storage-numeric-item
> (new format of RECORD contains-syntax with '85 Standard COBOL).

> Then make the 01 under your FD something like

>     01  My-File.
>           05  How-Many-bytes
>                     OCCURS 1 TO your-very-largest-vsam-record-size
>                     DEPENDING ON working-storage-numeric-item.
>             10  Each-byte-of-record   Pic X.

> As I say, I am not positive that this will work, but I think it might.

--
I've tried this - in fact, this is the code I am currently using in my
test.

Same results.

Any insights on how to get the address of the ACB?  I am already calling
an Assembler routine to allocate the files.  I'd like to  t r y  and use
the COBOL
ACB to open the file from the Assembler program after I allocate it.  

I know OS/VS COBOL is unsupported by IBM.  Are there any know problems
running
OS/VS COBOL after year 2000?  The system with the problems is due to be
retired, but most likely will not happen before  year 2000.



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Yeah, one.

It's not supported. This puts any application using it at risk "of failing with a
sudden death."

As I told some of my application programmers - "When it breaks, you own all of the
pieces."

Many companies that I am aware of are trying to get their programmers off of COBOL
VS II
and onto COBOL for MVS  long before the "no support date".

/s/ Bill Turner, wb4alm

================

Quote:


> > >--
> > > .
> > > .
> > >Do you know how to get the address of the files ACB from a COBOL
> > >program?


> > A couple of things (and mostly it sounds like you are close to needing
> > Assembler subroutines).

> > !) You absolutely can not (legaly) get the ACB address from any current
> > COBOL.  You can get at an FCB fro QSAM (by doing a CALL USING file-name) -
> > but IBM firmly rejected adding this facility for VSAM.

> > 2) What you might try (and I don't know if this will work or not) is

> > Change your FD to a RECORD VAYING IN SIZE FROM 1 TO
> > your-very-largest-vsam-record-size DEPENDING ON working-storage-numeric-item
> > (new format of RECORD contains-syntax with '85 Standard COBOL).

> > Then make the 01 under your FD something like

> >     01  My-File.
> >           05  How-Many-bytes
> >                     OCCURS 1 TO your-very-largest-vsam-record-size
> >                     DEPENDING ON working-storage-numeric-item.
> >             10  Each-byte-of-record   Pic X.

> > As I say, I am not positive that this will work, but I think it might.

> --
> I've tried this - in fact, this is the code I am currently using in my
> test.

> Same results.

> Any insights on how to get the address of the ACB?  I am already calling
> an Assembler routine to allocate the files.  I'd like to  t r y  and use
> the COBOL
> ACB to open the file from the Assembler program after I allocate it.

> I know OS/VS COBOL is unsupported by IBM.  Are there any know problems
> running
> OS/VS COBOL after year 2000?  The system with the problems is due to be
> retired, but most likely will not happen before  year 2000.



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

I deal with tape/cart files and have defined a generic input file of
5 to 32752 characters and the input dcb is defined as lrecl=32756 blksize=32760

This is what have worked for me being able to read any variable file.

I have yet to find a way to get the system to provide the RDW with each record.
If I had this is would make life much easier for me in determining the specific
record format to drip the record into.

Any ideas on receiving the RDW????



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files


  >sniped my last reply<

Quote:
>--
>I've tried this - in fact, this is the code I am currently using in my
>test.

>Same results.

>Any insights on how to get the address of the ACB?  I am already calling
>an Assembler routine to allocate the files.  I'd like to  t r y  and use
>the COBOL
>ACB to open the file from the Assembler program after I allocate it.

>I know OS/VS COBOL is unsupported by IBM.  Are there any know problems
>running
>OS/VS COBOL after year 2000?  The system with the problems is due to be
>retired, but most likely will not happen before  year 2000.

I agree with the other commenter that running OS/VS COBOL after Y2K is a bad
idea (because if it breaks, you're up a creek).  However, I know of no
specific problem that will bring it down.

Have you tried asking your question thru any of the IBM forums?  There may
be someone in IBM (or its user forums) who can come up with a suggestion. (I
would be going thru IBMLink; the ETR function, "ask a question". If you
aren't the person within your company who knows about this, check with a
system programmer who MIGHT be willing to help.)

My remaining COBOL solution is for you to put in an FD for each of the MAX
sizes and to have whatever program does the allocate to pass a flag
indicating what file was opened.  Then (assuming all your I/O statements are
done in a single place) you would just need to make each of them an EVALUATE
statement to process the right file.  Not very pretty, but it sounds like
what you may need to do.

P.S.  I am not one of those dinosaurs discussed in another thread who can
help you with the Assembler to get the ACB - I just know it can be done.



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Quote:

>I deal with tape/cart files and have defined a generic input file of
>5 to 32752 characters and the input dcb is defined as lrecl=32756
blksize=32760

>This is what have worked for me being able to read any variable file.

>I have yet to find a way to get the system to provide the RDW with each
record.
>If I had this is would make life much easier for me in determining the
specific
>record format to drip the record into.

>Any ideas on receiving the RDW????

For QSAM, this is easy.  Assuming you are using an 85 Standard COBOL (VS
COBOL II R3 or later, or COBOL for this-and-that), then just use the

    RECORD VAYING IN SIZE DEPENDING ON

option in your FD.  It won't give you direct access to the RDW, but it will
tell you exactly what value is in there.



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Quote:


> >I have an OS/VS COBOL program that has been converted to COBOL for MVS.
> >The program reads a variable length VSAM file.  There are thousands of
> >these files, anyone of which may be dynamically allocated to the
> >program.  The RECORD(avg,max) parm on IDCAMS DEFINE card varies between
> >files.
> >My problem - OS/VS COBOL did not require that the maximum length of a
> >file exactly match the file description within the program.  COBOL for
> >MVS requires that they match.  The program is taking an error on the
> >open statement with a file status of 39.  It also puts the follwing
> >message to sysout:

> >IGZ0201W A file attribute mismatch was detected. File DR-FILE in program
> >CART10 had a record length of 27000 and the file specified in the ASSIGN
> >clause had a record length of 22514.  It does not open the file.

> >Is there any way to get COBOL/MVS to handle this???  >
> >The open statement is generating a call to the COBOL run time IGZEVOP.

> >Any info would be appreciated.

> >--

> There is a pretty ugly work-around (not solution) which is to use the CMPR2
> compiler option.  This should end the FS=39, but it also means that you
> can't use any new '85 features or Intrinsic Functions.

> Does the maximum length in your program really match the largest size from
> your IDCAMS?   I thought that you could put a larger value in the FD and
> avoid the FS=39, but I could be completely wrong on that. (I I know that you
> get the error with an FD that is smaller than  the IDCAMS).

> P.S.  Do any of the VSAM files that you work with have alternate indexes?
> If so, you may run into another OS/VS COBOL vs COBOL for MVS issue.  You may
> have problems with programs that use a file defined with an alternate index
> via IDCAMS but not declared to have one in the COBOL source.  Just a
> warning, in case this turns out to be another problem.

The only way I found, after trying every permutation and contortion and
I could think of to handle variable-length records, the CMPR2 was the
only solution I found was possible.  There will have to be a trade-off
with the use of CMPR2, as William indicates.  Changes to the compiler to
demand that the attributes of the program match the DCB file attributes
for variable-length records was unnecessary and stupid of IBM.  But,
then, this isn't the first time I've had to deal with these types of
situations.

--
Mike Dodas

(Remove cutthejunk for e-mail replies)



Tue, 25 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files


    >lots of snip<

Quote:
>.  Changes to the compiler to
>demand that the attributes of the program match the DCB file attributes
>for variable-length records was unnecessary and stupid of IBM.  But,
>then, this isn't the first time I've had to deal with these types of
>situations.

>Mike Dodas

>(Remove cutthejunk for e-mail replies)

You can't completely blame IBM for this one.  This is related to a change in
the ANSI Standard which REQUIRES these types of attributes to be checked -
and an FS=39 to be issued when they don't.

On the other hand, IBM could have come up with an option to let you ignore
them - and run your program in a non-coforming way.  They have done that in
the past with everything from NODYNAM and APOST thru CBLQDA and CMPR2
itself.

FYI - the next Standard has a new way of "dynamically" deciding which file
to allocate at run-time. (See the new SELECT/USING variation of the old
SELECT/ASSIGN syntax.) Unfortunaly (for this particular prbolem), you still
need to have the same file attributes for each of the files in question.



Wed, 26 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files

Quote:



>     >lots of snip<
> >.  Changes to the compiler to
> >demand that the attributes of the program match the DCB file attributes
> >for variable-length records was unnecessary and stupid of IBM.  But,
> >then, this isn't the first time I've had to deal with these types of
> >situations.

> >Mike Dodas

> >(Remove cutthejunk for e-mail replies)

> You can't completely blame IBM for this one.  This is related to a change in
> the ANSI Standard which REQUIRES these types of attributes to be checked -
> and an FS=39 to be issued when they don't.

> On the other hand, IBM could have come up with an option to let you ignore
> them - and run your program in a non-coforming way.  They have done that in
> the past with everything from NODYNAM and APOST thru CBLQDA and CMPR2
> itself.

That's exactly what I meant.  

Quote:
> FYI - the next Standard has a new way of "dynamically" deciding which file
> to allocate at run-time. (See the new SELECT/USING variation of the old
> SELECT/ASSIGN syntax.) Unfortunaly (for this particular prbolem), you still
> need to have the same file attributes for each of the files in question.

If I understand your explanation to this new feature in the next
standard, then it is not truely dynamic.  If it were truely dynamic, you
should not have to worry about the attributes ahead of time.

--
Mike Dodas

(Remove cutthejunk for e-mail replies)



Wed, 26 Jul 2000 03:00:00 GMT  
 COBOL for MVS - var lenght files


Quote:



>>     >lots of snip<

>> FYI - the next Standard has a new way of "dynamically" deciding which
file
>> to allocate at run-time. (See the new SELECT/USING variation of the old
>> SELECT/ASSIGN syntax.) Unfortunaly (for this particular prbolem), you

still

Quote:
>> need to have the same file attributes for each of the files in question.

>If I understand your explanation to this new feature in the next
>standard, then it is not truely dynamic.  If it were truely dynamic, you
>should not have to worry about the attributes ahead of time.

>--
>Mike Dodas

>(Remove cutthejunk for e-mail replies)

It is completely dynamic for file-name (so you can chose what file you want
to use); it is not at all dynamic for attributes.  You *must* use a
pre-defined FD with all the "old" attributes that you have always needed.

This is intended for the type of program that sometimes reads in the daily
file or sometime the monthly file - but they all look alike.  It is not
intended for the type of program that wants to randomly read any file
without knowing ahead of time what it looks like.

I know some COBOLs (such as Micro Focus) that do provide facilities for
getting at the FCD and actually modifying it "on the fly" - but this has not
been proposed to the Standards committee. It is probably too late for this
next Standard, but if you think that this is something that should be added
to standard COBOL, I suggest that you propose it to J4.  If you want to know
how to do this, please feel free to send me an email and I will get you the
information on requesting stuff.



Wed, 26 Jul 2000 03:00:00 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Trace Cobol/MVS (LE/MVS) dynamic CALL

2. US - FL - S.E. ****MVS/CICS PROGRAMMERS (UNIX,MVS/TSO,ISPF,COBOL)****CONTRACT

3. Unix->MVS file transfer; MF COBOL

4. ??? - File Status Codes, COBOL For MVS, and COMPR2...

5. lenght of ntx files

6. Help with getting lenght of file.

7. File line lenght in Sun F90 V1.1

8. tandem COBOL to IBM Mainframe MVS COBOL Conversion

9. Differences between VS COBOL II and COBOL for MVS and VM

10. Bull Cobol vs MVS Cobol-II

11. US-MA Boston Area Contract Position: Cobol-Cobol II-DB2-MVS/JCL

12. Converting APS generated COBOL to COBOL for MVS

 

 
Powered by phpBB® Forum Software