Re: COBOL short variable length files????

[Clark Morris]

On 9 Jun 2005 11:48:57 -0700, in bit.listserv.ibm-main you wrote:

>Caveat:  I get the digest but am also behind on my reading so this 
>might already have been hashed over or be too late...
>-- 
>At June 6, 2005 11:38, concerning "COBOL short variable length 
>files", Andy Robertson <[EMAIL PROTECTED]> wrote (to IBM-
>Main):  
>
>> [snip] COBOL programs to tolerate short Variable Length files. I mean
>> the case where the FILE SECTION is 
>>   RECORD VARYING FROM nnn TO mmm
>> And your JCL is
>>   //DDNAME DD LRECL=qqq,RECFM=VB, . . .
>> [snip] we get
>> IGZ0201W  A file attribute mismatch was detected. [snip]
>> We would really like it to tolerate the case where qqq > mmm+4 [snip]
>
>I think you should drop the "FROM nnn TO mmm" then add "DEPENDING ON 
>data-name-1".  From the Cobol for MVS & VM Language Reference (2nd 
>ed, 1995 - SC26-4769-01), "If integer-6 (nnn) is not specified, the 
>minimum number ... least number ... for a record in that file." and 
>"If integer-7 (mmm) is not specified, the maximum ... greatest ... 
>for a record in that file." plus "If data-name-1 is specified: after 
>successful execution of a READ ... data-name-1 indicate the number 
>.. just read.  The number ... placed into ... data-name-1 before any 
>.. WRITE is executed..."  (I paraphrased big-time to reduce the size 
>of the e-mail but you get the gist.)
>
>Perhaps this'll swing you in the right direction with your Cobol 
>utility program conversion.
>
>ps.  You probably already know 'bout the additional, "When running 
>under MVS, BLOCK CONTAINS 0 ... size is determined at object time 
>from the DD ..."  ('RECORD CONTAINS 0' is only for *fixed* length 
>QSAM input.)


Several comments.

1.  I thought that specifying RECORDING U meant that the block was
read as a single record and included the blocksize as the first two
bytes if the file in fact was VB (or VBS).  I think I took advantage
of this years ago.  Since the last time I did this was before VS COBOL
II I don't know if you can specify DEPENDING ON data-name-1 for
RECORDING U files although it would be helpful.

2. I also think that if RECORDING U is specified for an output file,
the record area is the same as the block and the length of the record
actually being written is determine by the description of the 01 being
written.

3. If you have a COBOL program with either BLOCK 0 QSAM file or a VSAM
file described with RECORD DEPENDING ON data-name, the file is assumed
variable with the maximum record size being determined by the largest
record described by an 01.  This size must match the record size
described in the VTOC/tape label adjusted by the Record descriptor
word.  This limitation was enraging when dealing with files containing
SMF records.  I am not certain whether you are allowed to ignore a
STATUS code 39 and proceed to use an input file.  1  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Neil Duffee]

Caveat:  I get the digest but am also behind on my reading so this 
might already have been hashed over or be too late...
-- 
At June 6, 2005 11:38, concerning "COBOL short variable length 
files", Andy Robertson <[EMAIL PROTECTED]> wrote (to IBM-
Main):  

> [snip] COBOL programs to tolerate short Variable Length files. I mean
> the case where the FILE SECTION is 
>   RECORD VARYING FROM nnn TO mmm
> And your JCL is
>   //DDNAME DD LRECL=qqq,RECFM=VB, . . .
> [snip] we get
> IGZ0201W  A file attribute mismatch was detected. [snip]
> We would really like it to tolerate the case where qqq > mmm+4 [snip]

I think you should drop the "FROM nnn TO mmm" then add "DEPENDING ON 
data-name-1".  From the Cobol for MVS & VM Language Reference (2nd 
ed, 1995 - SC26-4769-01), "If integer-6 (nnn) is not specified, the 
minimum number ... least number ... for a record in that file." and 
"If integer-7 (mmm) is not specified, the maximum ... greatest ... 
for a record in that file." plus "If data-name-1 is specified: after 
successful execution of a READ ... data-name-1 indicate the number 
... just read.  The number ... placed into ... data-name-1 before any 
... WRITE is executed..."  (I paraphrased big-time to reduce the size 
of the e-mail but you get the gist.)

Perhaps this'll swing you in the right direction with your Cobol 
utility program conversion.

ps.  You probably already know 'bout the additional, "When running 
under MVS, BLOCK CONTAINS 0 ... size is determined at object time 
from the DD ..."  ('RECORD CONTAINS 0' is only for *fixed* length 
QSAM input.)
-->  signature = 6 lines follows <--
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer 2004

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/06/2005
   at 10:31 PM, Joe Zitzelberger <[EMAIL PROTECTED]> said:

>Just another case of the system showing its age in the 21st
>century...

Not really; I would have considered that behavior to be broken back on
OS/360.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/06/2005
   at 10:52 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>you wouldn't have that problem on UNIX.

Only because it doesn't have the functionality at all.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Ted MacNEIL]

...
The difference (that I know of) for Recording Mode is U - STARTED with
OS/390 2.10 - not after it.  Check out:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG20/3.5.3 
...

We were okay on Friday.
We converted from 2.10 to 1.4.
It was broken on Monday.
Both existing programmes and new compiles.

But, I shall check your reference.

No speak-ah dah COBOL good.
(Haven't written one since 1st year university -- 197x).


-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Ted MacNEIL]

I don't know if this is related or not, but we converted from OS/390 2.10 to 
z/OS 1.4, this past weekend.

We did not convert COBOL or LE.

According to a developer, an extra four bytes (for blocksize) is added to the 
data for

RECORDING MODE IS U.

Has anybody every heard of this?
Where is the doc?

-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Ed Finnell]

 
In a message dated 6/7/2005 8:25:53 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

IBM, in  contrast, tried to coerce perforated tape into the unit record
mold.   I recall that there were legendary difficulties reading on a 1620
tapes  that lacked the necessary record separator codes.  I think the
symptom  was overflowing buffer and wrapping memory.  I don't know if
it  stopped when the READ instruction was finally overlaid.  I  don't
recall whether the deficiency was in the control unit or the  FORTRAN
runtime system.



>>
One of my first real jobs was hooking a 33ASR to an 029. So
the AT&T toll information could be 'punched' for the billing
system. The AT&T tech couldn't view the IBM manual and the IBM CE
couldn't view the AT&T by copyright/legal working agreement.
We put an eight pin terminator strip on the wall between
the two machines. Didn't work. Well, what's you DTR---finally
the IBM guy needed a break and laid his manual to the page
on the 029. We decided we need a break too and laid our manual
on the chair to the page-funny thing after the break was over.
The thing started to work! 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Paul Gilmartin]

In a recent note, Joe Zitzelberger said:

> Date: Tue, 7 Jun 2005 08:38:25 -0400
> 
> The most effective type of birth control is learning Cobol.  -DT
> 
I can't conceive a fascination with COBOL so intense that I couldn't
conceive.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Paul Gilmartin]

In a recent note, Joe Zitzelberger said:

> Date: Tue, 7 Jun 2005 08:38:25 -0400
> 
> The big difference that I see is that z/OS keeps design decisions
> around long after the need for them is gone.  For example, Unix dropped
> 'card' type metaphors as soon as readers and punches departed -- z/OS
> still has them in every nook and cranny a quarter of a century later.
> There are many other examples, but I've held forth on those at length
> previously, there is no need to do so again.
> 
Credit for the difference may be due more to historical accident than to
cultural differences.  In my dim memory the ancestral open systems arose
with perforated tape rather than cards as the modal input and storage
medium.  (Paper tape readers are mechanically simpler, thus cheaper, than
card readers.)  So the design was not oriented to unit records.

IBM, in contrast, tried to coerce perforated tape into the unit record
mold.  I recall that there were legendary difficulties reading on a 1620
tapes that lacked the necessary record separator codes.  I think the
symptom was overflowing buffer and wrapping memory.  I don't know if
it stopped when the READ instruction was finally overlaid.  I don't
recall whether the deficiency was in the control unit or the FORTRAN
runtime system.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Tuesday, June 07, 2005 8:12 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: COBOL short variable length files
> 



> Doesn't the standard support portability of COBOL programs to 
> platforms
> that don't maintain LRECL as metadata?  If so, the standard can't
> require validation of LRECL, since that isn't guaranteed to be
> available.  It should be permissible simply to perform no such check.
> 
> -- gil
> -- 

And have the UNIX problem when somebody reads a record into a buffer
which is too small to hold it. Classic buffer overflow problem. At least
on z/OS, the program dies instead of quietly producing junk. We have
other ways to quietly produce junk .


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Paul Gilmartin]

In a recent note, Clark Morris said:

> Date: Tue, 7 Jun 2005 09:35:44 -0300
> 
> The problem has nothing to do with z/OS vs. Unix.  It is a simple
> IDIOTIC check that can't be disabled.  It may make sense for fixed
> 
The thrust of my remark was that since UNIX maintains no metadata
similar to LRECL, no such check is possible, and no such delusional
error can be IDIOTICally reported.  I suppose I can be accused of
some inconsistency since I lately hailed UNIX for dutifully maintaining
other metadata (file timestamps).  But UNIX programs don't often fail
because the system insists on validating a timestamp.

> block.  The whole issue should be revisited by the COBOL compiler
> group.  The 2002 COBOL standard might allow a graceful way for the
> compiler group to make the appropriate changes.  In one sense the
> SHARE requirement might be to honor the Language Futures Task Force
> report.  This would also have some other interesting advantages such
> as allowing COBOL programs to read or write either ESDS or QSAM files
> without program modification.
> 
Doesn't the standard support portability of COBOL programs to platforms
that don't maintain LRECL as metadata?  If so, the standard can't
require validation of LRECL, since that isn't guaranteed to be
available.  It should be permissible simply to perform no such check.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Joe Zitzelberger]

On Jun 6, 2005, at 11:52 PM, Paul Gilmartin wrote:

In a recent note unmask]> said:


Date: Mon, 6 Jun 2005 22:31:05 -0400


IGZ0201W  A file attribute mismatch was detected. File DDNAME in
program
xxx had a record length of mmm+4 and the file specified in the
ASSIGN
clause had a record length of qqq.


My specific problem was that I wanted to describe a record as the set
of all possible variable records:

RECORD VARYING FROM 5 TO 32761

And then to be able to open any variable blocked file.

Just another case of the system showing its age in the 21st century...


Someone in this group lately called UNIX "radically immature".  Now you
see z/OS as superannuated.  UNIX appears to me to be in its robust 
prime:

you wouldn't have that problem on UNIX.

-- gil
--
StorageTek
INFORMATION made POWERFUL


The both date back to the jurassic age of computing -- 1970 isn't 
exactly new. And 36 years compared to 41 years is just about the same 
in the grand scheme of things.


The big difference that I see is that z/OS keeps design decisions 
around long after the need for them is gone.  For example, Unix dropped 
'card' type metaphors as soon as readers and punches departed -- z/OS 
still has them in every nook and cranny a quarter of a century later.  
There are many other examples, but I've held forth on those at length 
previously, there is no need to do so again.


What I find most humorous about the above LRECL/FD agreement problem is 
that IBM's Cobol now supports parsing modern XML, but makes it almost 
impossible to read such content from a Data Set using their flagship 
compiler.  After all, it must be an error if you don't know the size of 
the card deck you are putting into the reader...



[EMAIL PROTECTED]

The most effective type of birth control is learning Cobol.  -DT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Clark Morris]

On 6 Jun 2005 20:52:17 -0700, in bit.listserv.ibm-main you wrote:

>In a recent note unmask]> said:
>
>> Date: Mon, 6 Jun 2005 22:31:05 -0400
>> >
>> > IGZ0201W  A file attribute mismatch was detected. File DDNAME in
>> > program
>> > xxx had a record length of mmm+4 and the file specified in the
>> > ASSIGN
>> > clause had a record length of qqq.
>>
>> My specific problem was that I wanted to describe a record as the set
>> of all possible variable records:
>>
>> RECORD VARYING FROM 5 TO 32761
>>
>> And then to be able to open any variable blocked file.
>>
>> Just another case of the system showing its age in the 21st century...
>>
>Someone in this group lately called UNIX "radically immature".  Now you
>see z/OS as superannuated.  UNIX appears to me to be in its robust prime:
>you wouldn't have that problem on UNIX.
>
>-- gil

The problem has nothing to do with z/OS vs. Unix.  It is a simple
IDIOTIC check that can't be disabled.  It may make sense for fixed
block.  The whole issue should be revisited by the COBOL compiler
group.  The 2002 COBOL standard might allow a graceful way for the
compiler group to make the appropriate changes.  In one sense the
SHARE requirement might be to honor the Language Futures Task Force
report.  This would also have some other interesting advantages such
as allowing COBOL programs to read or write either ESDS or QSAM files
without program modification.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Andy Robertson]

On Mon, 6 Jun 2005 22:31:05 -0400, Joe Zitzelberger <[EMAIL PROTECTED]> >

>I think though, the best solution is a simple assembler subprogram.
>
>


Thanks for all comments, thoughts, etc.The problem is that we already
have a "simple assembler subprogram" (well, not that simple) and I'm the
one charged with converting it to HLL.


Ah well, IBM foils us again.   Never mind, at least it puts off the day we
convert to Honeywell or whatever.   ;-)

.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Paul Gilmartin]

In a recent note unmask]> said:

> Date: Mon, 6 Jun 2005 22:31:05 -0400
> >
> > IGZ0201W  A file attribute mismatch was detected. File DDNAME in
> > program
> > xxx had a record length of mmm+4 and the file specified in the
> > ASSIGN
> > clause had a record length of qqq.
>
> My specific problem was that I wanted to describe a record as the set
> of all possible variable records:
>
> RECORD VARYING FROM 5 TO 32761
>
> And then to be able to open any variable blocked file.
>
> Just another case of the system showing its age in the 21st century...
>
Someone in this group lately called UNIX "radically immature".  Now you
see z/OS as superannuated.  UNIX appears to me to be in its robust prime:
you wouldn't have that problem on UNIX.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Joe Zitzelberger]

On Jun 6, 2005, at 12:38 PM, Andy Robertson wrote:
I seem to remember a discussion here about a PTF, trick or Compiler 
option
that would allow the latest flavours of COBOL programs to tolerate 
short

Variable Length files.

I mean the case where the FILE SECTION is

  RECORD VARYING FROM nnn TO mmm

And your JCL is

  //DDNAME DD LRECL=qqq,RECFM=VB, . . .


Now, it seems that qqq must equal mmm+4 or we get

IGZ0201W  A file attribute mismatch was detected. File DDNAME in 
program
xxx had a record length of mmm+4 and the file specified in the 
ASSIGN

clause had a record length of qqq.

We would really like it to tolerate the case where qqq > mmm+4


I am sure I remember a discussion of this here and I think I remember 
some

one suggesting a bypass, trick or fix, but numerous searchges have not
turned it up.

Am I deraming, or can any one remember or give me some sort of hint???

TIA


I recall searching for a way to do something similar to this a few 
years ago.


My specific problem was that I wanted to describe a record as the set 
of all possible variable records:


RECORD VARYING FROM 5 TO 32761

And then to be able to open any variable blocked file.

I ran afoul the same IGZ0201W message telling me that a 
LRECL=x,RECFM=VB file did not fit that description. My solution was a 
simple assembler program which makes this trivial problem go away.  I 
never found a way to finagle the Cobol compiler into acknowledging that 
all records of a VB file would fit within a larger variable file.  It 
insisted on cross checking the JCL on the OPEN.


Just another case of the system showing its age in the 21st century...

If you want the JCL to be greater than the FD your only option is to 
open it in unformatted mode and unblock it yourself -- but IIRC the 
compiler will scream at you if the JCL does not contain a RECFM=U.  So 
that might not be any help as you would still need to change 2000+ JCL 
decks.


You could write a LE abend handler to trap that specific message and 
resume -- that is easy enough, but is hardly a Cobolesse solution.


You might try a FILE-STATUS clause, in some cases, if it is specified 
for a file you can receive control back after a failed OPEN.


I think though, the best solution is a simple assembler subprogram.


[EMAIL PROTECTED]

Q: How many Marxist revolutionaries does it take to change a 
proletarian lightbulb?


A: None.  A proletarian lightbulb contains the seeds of its own 
revolution.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Charles Mills]

Why can't the RECORD clause in the new COBOL be bumped up such that it
matches LRECL-4?

Or are the LRECLs somewhat different from JCL deck to JCL deck?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Andy Robertson
Sent: Monday, June 06, 2005 10:16 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL short variable length files


On Mon, 6 Jun 2005 10:02:47 -0700, Charles Mills <[EMAIL PROTECTED]>
wrote:


Output, but the situation is more general than that.   The usual mass of
backward compatibility and non-technical/financial constraints.

We have a widely used Assembler subroutine that was employed to paginate
reports.   As part of a long term policy from on high we are working to
convert this to HLL which means C or COBOL here.

So there are umpty beaucoup different jobs which depend on the assembler
routine tolerating this quirk.

If the COBOL one doesn't tolerate it we have to fix maybe 2000 JCL decks
or do something clever, and the whole point of rewriting in HLL is NOT
to do something clever.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Charles Mills]

He is looking to tolerate the case where the LRECL is GREATER than
(COBOL RECORD clause + 4). 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Klein
Sent: Monday, June 06, 2005 12:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Fw: COBOL short variable length files


The LRECL in the JCL includes the RDW.  The "RECORD VARYING IN SIZE"
does
*not* include the RDW.  Therefore, it is quite true that the LRECL (in
JCL) should be 4-bytes larger than the minimum RECORD VARING FROM value.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Mike Bell]

You are looking for spanned records - ie RECFM=VBS.  
The COBOL manual has the necessary information.
Also note the difference of using WRITE vs WRITE FROM.
WRITE FROM is required for VBS because that is the only way you can
build a bigger than blksize record.

Mike

On 6/6/05, Andy Robertson <[EMAIL PROTECTED]> wrote:
> I seem to remember a discussion here about a PTF, trick or Compiler option
> that would allow the latest flavours of COBOL programs to tolerate short
> Variable Length files.
> 
> 
> I mean the case where the FILE SECTION is
> 
>   RECORD VARYING FROM nnn TO mmm
> 
> And your JCL is
> 
>   //DDNAME DD LRECL=qqq,RECFM=VB, . . .
> 
> 
> Now, it seems that qqq must equal mmm+4 or we get
> 
> IGZ0201W  A file attribute mismatch was detected. File DDNAME in program
> xxx had a record length of mmm+4 and the file specified in the ASSIGN
> clause had a record length of qqq.
> 
> We would really like it to tolerate the case where qqq > mmm+4
> 
> 
> I am sure I remember a discussion of this here and I think I remember some
> one suggesting a bypass, trick or fix, but numerous searchges have not
> turned it up.
> 
> Am I deraming, or can any one remember or give me some sort of hint???
> 
> TIA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 


-- 
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Andy Robertson]

On Mon, 6 Jun 2005 10:02:47 -0700, Charles Mills <[EMAIL PROTECTED]> wrote:

>If DDNAME is being opened for input, can you get away with overriding
>the LRECL? That is, explicitly coding
>
>//DDNAME DD LRECL=mmm+4, ...
>
>Even though the DSCB LRECL is greater than that - although presumably
>the maximum length of any record in the file, or any record that you are
>actually going to read, is no greater than mmm+4.
>
>If not, perhaps a little background would help. Is this an input or an
>output file? Why would you want to do this? COBOL seems like it is
>trying to keep you out of trouble.


Output, but the situation is more general than that.   The usual mass of
backward compatibility and non-technical/financial constraints.

We have a widely used Assembler subroutine that was employed to paginate
reports.   As part of a long term policy from on high we are working to
convert this to HLL which means C or COBOL here.

So there are umpty beaucoup different jobs which depend on the assembler
routine tolerating this quirk.

If the COBOL one doesn't tolerate it we have to fix maybe 2000 JCL decks
or do something clever, and the whole point of rewriting in HLL is NOT to
do something clever.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL short variable length files????

[Charles Mills]

If DDNAME is being opened for input, can you get away with overriding
the LRECL? That is, explicitly coding 

//DDNAME DD LRECL=mmm+4, ... 

Even though the DSCB LRECL is greater than that - although presumably
the maximum length of any record in the file, or any record that you are
actually going to read, is no greater than mmm+4.

If not, perhaps a little background would help. Is this an input or an
output file? Why would you want to do this? COBOL seems like it is
trying to keep you out of trouble.

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Andy Robertson
Sent: Monday, June 06, 2005 9:39 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: COBOL short variable length files


I seem to remember a discussion here about a PTF, trick or Compiler
option that would allow the latest flavours of COBOL programs to
tolerate short Variable Length files.


I mean the case where the FILE SECTION is

  RECORD VARYING FROM nnn TO mmm

And your JCL is

  //DDNAME DD LRECL=qqq,RECFM=VB, . . .


Now, it seems that qqq must equal mmm+4 or we get

IGZ0201W  A file attribute mismatch was detected. File DDNAME in program
xxx had a record length of mmm+4 and the file specified in the
ASSIGN clause had a record length of qqq.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html