How Many COBOL Programs Does It Take To Change A Light Bulb? 
Author Message
 How Many COBOL Programs Does It Take To Change A Light Bulb?

...actually, I'm wondering how many COBOL programs it takes to copy variable
length files!

Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like if
one wants to copy variable length files with LRECLs ranging from 1 to 32768
bytes, one would need 32768 separate programs to avoid File Status 39 open
errors - even using ...DEPENDING ON clauses - since COBOL seems to demand that
the maximum possible record length (determined at compile time) be no greater
than the file's actual LRECL!

Someone (knowledgeable, not guessing) please tell me what I'm doing wrong, or
it's time to round up the {*filter*} mob for the Standards folks!



Wed, 14 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?
COBOL for MVS (like all other ANS'85 Standard conforming compilers) *does*
require that you know the record length (as defined in the physical file
attributes) when you write your source code.

Therefore, if you really know what file you are going to use, then you only
need 1 FD.  If you do NOT know the physical file attributes of your input
file, when you write your source code, then you will in deed have a problem.

Quote:

>...actually, I'm wondering how many COBOL programs it takes to copy
variable
>length files!

>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like
if
>one wants to copy variable length files with LRECLs ranging from 1 to 32768
>bytes, one would need 32768 separate programs to avoid File Status 39 open
>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
that
>the maximum possible record length (determined at compile time) be no
greater
>than the file's actual LRECL!

>Someone (knowledgeable, not guessing) please tell me what I'm doing wrong,
or
>it's time to round up the {*filter*} mob for the Standards folks!



Wed, 14 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

>...actually, I'm wondering how many COBOL programs it takes to copy
variable
>length files!

>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like
if
>one wants to copy variable length files with LRECLs ranging from 1 to 32768
>bytes, one would need 32768 separate programs to avoid File Status 39 open
>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
that
>the maximum possible record length (determined at compile time) be no
greater
>than the file's actual LRECL!

>Someone (knowledgeable, not guessing) please tell me what I'm doing wrong,
or
>it's time to round up the {*filter*} mob for the Standards folks!

Actually you can use one simple program if the files are not ISAM files.  To
READ records from a file with variable length records terminated with ASCII
<nl> simply ASSIGN the file to KEYBOARD and make sure your FD record length
is at least as large as the largest record you will encounter.  Similarly,
to write the records ASSIGN the file to PRINTER and define each of your
32,000 records in the FD and write the record with the appropriate length.
Beyond the teditious task of writing all the different records this is not a
tough problem.

On the other hand, if you are fortunate enough to have Acucobol you can just
use their C$COPY library to copy the files and do it with one CALL
statement.

Regards,
Sal



Wed, 14 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

>...actually, I'm wondering how many COBOL programs it takes to copy
variable
>length files!

>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like
if
>one wants to copy variable length files with LRECLs ranging from 1 to 32768
>bytes, one would need 32768 separate programs to avoid File Status 39 open
>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
that
>the maximum possible record length (determined at compile time) be no
greater
>than the file's actual LRECL!

>Someone (knowledgeable, not guessing) please tell me what I'm doing wrong,
or
>it's time to round up the {*filter*} mob for the Standards folks!

Can you give us some more information on what type of input data you have.
What's the input file consist of?  What, exactly (not partially), is going
on?


Wed, 14 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?
This post must have missed the critical information that this was a question
about "COBOL for MVS".  The answer given does NOT match the question.

Quote:


>>...actually, I'm wondering how many COBOL programs it takes to copy
>variable
>>length files!

>>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like
>if
>>one wants to copy variable length files with LRECLs ranging from 1 to
32768
>>bytes, one would need 32768 separate programs to avoid File Status 39 open
>>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
>that
>>the maximum possible record length (determined at compile time) be no
>greater
>>than the file's actual LRECL!

>>Someone (knowledgeable, not guessing) please tell me what I'm doing wrong,
>or
>>it's time to round up the {*filter*} mob for the Standards folks!

>Actually you can use one simple program if the files are not ISAM files.
To
>READ records from a file with variable length records terminated with ASCII
><nl> simply ASSIGN the file to KEYBOARD and make sure your FD record length
>is at least as large as the largest record you will encounter.  Similarly,
>to write the records ASSIGN the file to PRINTER and define each of your
>32,000 records in the FD and write the record with the appropriate length.
>Beyond the teditious task of writing all the different records this is not
a
>tough problem.

>On the other hand, if you are fortunate enough to have Acucobol you can
just
>use their C$COPY library to copy the files and do it with one CALL
>statement.

>Regards,
>Sal



Wed, 14 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:
><HTML><PRE>Subject: Re: How Many COBOL Programs Does It Take To Change A
>Light Bulb?

>Date: Sat, Sep 26, 1998 16:09 EDT


>>...actually, I'm wondering how many COBOL programs it takes to copy
>variable
>>length files!

>>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks like
>if
>>one wants to copy variable length files with LRECLs ranging from 1 to 32768
>>bytes, one would need 32768 separate programs to avoid File Status 39 open
>>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
>that
>>the maximum possible record length (determined at compile time) be no
>greater
>>than the file's actual LRECL!

>>Someone (knowledgeable, not guessing) please tell me what I'm doing wrong,
>or
>>it's time to round up the {*filter*} mob for the Standards folks!

>Can you give us some more information on what type of input data you have.
>What's the input file consist of?  What, exactly (not partially), is going
>on?

></PRE></HTML>

Other stuff is going on, but for the purposes of this issue, just assume you
have to read records from variable length files (different LRECLs) using ONE
program compiled with COBOL For MVS.

The program is to be used with all the variable length files within a system,
and therein lies the rub. For the COBOL For MVS program to work, it looks like
the maximum LRECL in the program must agree with the physical files, or a
failure occurs at run-time.

An earlier post indicated this was the case. I hope someone can prove
otherwise, but I'd tend to agree based upon my coworker's efforts and the COBOL
for MVS documentation.



Thu, 15 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

><snip
>>>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks
like if
>>>one wants to copy variable length files with LRECLs ranging from 1 to
32768
>>>bytes, one would need 32768 separate programs to avoid File Status 39
open
>>>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
that
>>>the maximum possible record length (determined at compile time) be no
greater
>>>than the file's actual LRECL!

>>>Someone (knowledgeable, not guessing) please tell me what I'm doing
wrong, or
>>>it's time to round up the {*filter*} mob for the Standards folks!

>>Can you give us some more information on what type of input data you have.
>>What's the input file consist of?  What, exactly (not partially), is going
>>on?

>Other stuff is going on, but for the purposes of this issue, just assume
you
>have to read records from variable length files (different LRECLs) using
ONE
>program compiled with COBOL For MVS.

>The program is to be used with all the variable length files within a
system,
>and therein lies the rub. For the COBOL For MVS program to work, it looks
like
>the maximum LRECL in the program must agree with the physical files, or a
>failure occurs at run-time.

>An earlier post indicated this was the case. I hope someone can prove
>otherwise, but I'd tend to agree based upon my coworker's efforts and the
COBOL
>for MVS documentation.

Theo,

But what _sort_ of variable length record files are you talking about?
Comma delimited?  RECFM=VB?  VSAM.  What?

If it is RECFM=VB, then I don't see what the problem is.  You say Depending
On isn't working.  But you didn't say for certain that the files are or
aren't RECFM=VB, so I can't go farther with this.

You said . . .

Quote:
>Other stuff is going on, but for the purposes of this issue, just assume
you
>have to read records from variable length files (different LRECLs) using
ONE
>program compiled with COBOL For MVS.

. . . I can't just assume variable length files, I have to know what the
file type is.  The file type governs what happens to the Depending On
clause.


Fri, 16 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:
><HTML><PRE>Subject: Re: How Many COBOL Programs Does It Take To Change A
>Light Bulb?

>Date: Mon, Sep 28, 1998 11:42 EDT


>><snip
>>>>Using COBOL For MVS (NOCMPR2) without assembler subroutines, it looks
>like if
>>>>one wants to copy variable length files with LRECLs ranging from 1 to
>32768
>>>>bytes, one would need 32768 separate programs to avoid File Status 39
>open
>>>>errors - even using ...DEPENDING ON clauses - since COBOL seems to demand
>that
>>>>the maximum possible record length (determined at compile time) be no
>greater
>>>>than the file's actual LRECL!

>>>>Someone (knowledgeable, not guessing) please tell me what I'm doing
>wrong, or
>>>>it's time to round up the {*filter*} mob for the Standards folks!

>>>Can you give us some more information on what type of input data you have.
>>>What's the input file consist of?  What, exactly (not partially), is going
>>>on?

>>Other stuff is going on, but for the purposes of this issue, just assume
>you
>>have to read records from variable length files (different LRECLs) using
>ONE
>>program compiled with COBOL For MVS.

>>The program is to be used with all the variable length files within a
>system,
>>and therein lies the rub. For the COBOL For MVS program to work, it looks
>like
>>the maximum LRECL in the program must agree with the physical files, or a
>>failure occurs at run-time.

>>An earlier post indicated this was the case. I hope someone can prove
>>otherwise, but I'd tend to agree based upon my coworker's efforts and the
>COBOL
>>for MVS documentation.

>Theo,

>But what _sort_ of variable length record files are you talking about?
>Comma delimited?  RECFM=VB?  VSAM.  What?

>If it is RECFM=VB, then I don't see what the problem is.  You say Depending
>On isn't working.  But you didn't say for certain that the files are or
>aren't RECFM=VB, so I can't go farther with this.

>You said . . .
>>Other stuff is going on, but for the purposes of this issue, just assume
>you
>>have to read records from variable length files (different LRECLs) using
>ONE
>>program compiled with COBOL For MVS.
>. . . I can't just assume variable length files, I have to know what the
>file type is.  The file type governs what happens to the Depending On
>clause.

></PRE></HTML>

Seems like I'm throwing good time after bad on this issue (i.e., the earlier
recommendation to use IEBGENER to copy every file before you read it comes to
mind!), but I'll take one last stab at being VERY SPECIFIC:

Code ONE FD for a COBOL For MVS program that can be used to simply read in VB,
QSAM files of ANY valid LRECL.

Sounds simple enough (seems to me like the same program should be able to be
used for sequential and FB and VSAM, but I'm trying to "think small" for the
time being) , but I think I'm SOL.



Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

>Seems like I'm throwing good time after bad on this issue (i.e., the earlier
>recommendation to use IEBGENER to copy every file before you read it comes to
>mind!), but I'll take one last stab at being VERY SPECIFIC:

>Code ONE FD for a COBOL For MVS program that can be used to simply read in VB,
>QSAM files of ANY valid LRECL.

>Sounds simple enough (seems to me like the same program should be able to be
>used for sequential and FB and VSAM, but I'm trying to "think small" for the
>time being) , but I think I'm SOL.

The answer is one FD, but only if you know the length of the file at
runtime.

fd needs to contain a record contains 0 clause, and a recording mode of
undefined. If a recording mode of V is used, the rec length will default
to the max defined in the occurs depending.

FD  INFILE01                                                
    RECORD CONTAINS 0                                        
    RECORDING MODE IS U.                                    
01  INFILE01-REC.                                            
    05  INFILE01-REC-CHAR OCCURS 1 TO 32000                  
                          DEPENDING ON WS-REC-LEN PIC X(01).

And then somewhere in working storage a  WS-REC-LEN field needs to be
defined. This field needs to be initialized prior to an open of the file.

Suggested methods for initializing the  WS-REC-LEN field are
reading the length from another file
passing the length as a parm in the exec pgm=



Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

>fd needs to contain a record contains 0 clause, and a recording mode of
>undefined. If a recording mode of V is used, the rec length will default
>to the max defined in the occurs depending.

As a followup, the same program could be used to read fixed length records
also.


Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

<snip>

Quote:
>>Theo,

>>But what _sort_ of variable length record files are you talking about?
>>Comma delimited?  RECFM=VB?  VSAM.  What?

>>If it is RECFM=VB, then I don't see what the problem is.  You say
Depending
>>On isn't working.  But you didn't say for certain that the files are or
>>aren't RECFM=VB, so I can't go farther with this.

>>You said . . .
>>>Other stuff is going on, but for the purposes of this issue, just assume
>>you
>>>have to read records from variable length files (different LRECLs) using
>>ONE
>>>program compiled with COBOL For MVS.
>>. . . I can't just assume variable length files, I have to know what the
>>file type is.  The file type governs what happens to the Depending On
>>clause.

>></PRE></HTML>

>Seems like I'm throwing good time after bad on this issue (i.e., the
earlier
>recommendation to use IEBGENER to copy every file before you read it comes
to
>mind!), but I'll take one last stab at being VERY SPECIFIC:

Well!  There's no need to get upset.

Quote:
>Code ONE FD for a COBOL For MVS program that can be used to simply read in
VB,
>QSAM files of ANY valid LRECL.

>Sounds simple enough (seems to me like the same program should be able to
be
>used for sequential and FB and VSAM, but I'm trying to "think small" for
the
>time being) , but I think I'm SOL.

Ok, how about this (and no, I've never tried it, so feel free to think this
is a waste of time, too).
Note, I'm using 32752 as record length, because 32756 is the maximum JCL
lrecl allowed in MVS/XA 2.2.3 when using recfm=VB (unless you are using
spanned records, but you didn't mention that, so I won't assume it).

FD  any-length-file
        recording mode is v
        record varying from 1 to 32752 characters
            depending on length-variable.

01   any-length-rec

        05 any-length-array
             occurs 1 to 32752 times
             depending on length-variable
             indexed by any-length-idx.

             10  any-length-singlechar                   pic x(01).

What I don't know will work is having the 01 group item have a DEPENDING ON
data-item that is the same as the FD's.  If it doesn't, you'll have to
figure out a workaround.  If it does work, you are then free to either work
with the array using locate-mode I/O, or copy the array to working-storage
using move-mode I/O.

Full Code
IDENTIFICATION DIVISION.
PROGRAM-ID.    PROGRAM1.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT ANY-LENGTH-FILE   ASSIGN TO OUTFILE1.
DATA DIVISION.
FILE SECTION.

FD  ANY-LENGTH-FILE
       RECORDING MODE IS V
       RECORD VARYING FROM 1 TO 32752 CHARACTERS
             DEPENDING ON LENGTH-VARIABLE.

01  ANY-LENGTH-REC.

    05  ANY-LENGTH-ARRAY
          OCCURS 1 TO 32752 TIMES
          DEPENDING ON LENGTH-VARIABLE
          INDEXED BY ANY-LENGTH-IDX.

         10  ANY-LENGTH-SINGLECHAR        PIC  X(01).

WORKING-STORAGE SECTION.

01  ACCUMULATORS.

    05  ANY-LENGTH-CNTR     PIC S9(08) VALUE +1

BINARY SYNC.

    05  LOOP-CNTR                   PIC S9(08) VALUE ZEROS

BINARY SYNC.

01  FILE-VARIABLES.

    05  LENGTH-VARIABLE      PIC  9(08) VALUE ZEROS

BINARY SYNC.

PROCEDURE DIVISION.

MAIN-PARAGRAPH.

    OPEN OUTPUT ANY-LENGTH-FILE

    PERFORM
        UNTIL ANY-LENGTH-REC = 32756
        PERFORM
            VARYING ANY-LENGTH-IDX
               FROM 1
                     BY 1
            UNTIL LOOP-CNTR >= ANY-LENGTH-CNTR
                  MOVE 'Z'
                              TO
                              ANY-LENGTH-SINGLECHAR (ANY-LENGTH-IDX)
                 SET LOOP-CNTR TO ANY-LENGTH-IDX
        END-PERFORM
        SET LENGTH-VARIABLE TO ANY-LENGTH-IDX
        DISPLAY ANY-LENGTH-REC
        WRITE ANY-LENGTH-REC
        ADD 1 TO ANY-LENGTH-CNTR
        DISPLAY ANY-LENGTH-CNTR
        MOVE LOW-VALUES TO ANY-LENGTH-REC
    END-PERFORM

    CLOSE ANY-LENGTH-FILE
    .

The output matched what I expected (okay, the first record had only
low-values, and the last byte of every record had low-values, but that's
only because I didn't design the loop correctly; you'll have to forgive me,
I just rambo coded it).

Now, you are probably, saying, this is a OUTPUT, not a read.  Right?  Of
course, I don't have a source file with a massive number of variable records
of differing kinds, so I had to create one.  If I can create one with one
FD, you bet I can read one with one FD.

Note, running this with that last display statement can produce an awfully
long JES2 spool queue sysout member, and you'll need quite a bit of space
for the dataset, but it does work.

I would also like to suggest the VS COBOL II Application Programming
Language Reference, it has an excellent (if brief) section on Depends on in
the FD clause, and the conditions deriving therefrom.

I hope this wasn't a waste of your time.



Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:
>Seems like I'm throwing good time after bad on this issue (i.e., the earlier
>recommendation to use IEBGENER to copy every file before you read it comes to
>mind!), but I'll take one last stab at being VERY SPECIFIC:

>Code ONE FD for a COBOL For MVS program that can be used to simply read in VB,
>QSAM files of ANY valid LRECL.

PMJI,

am I misunderstanding something?  (that DOES happen from time to time, you know) -  What
would be wrong with the following program:

000010 CBL TRUNC(BIN)
000100 Identification Division.
000200  Program-Id. VarRead.
000300 Environment Division.
000400  Input-Output Section.
000500   File-Control.
000600     Select VarFile ASSIGN TO VarFile
000700                    ORGANIZATION IS SEQUENTIAL
000800                    ACCESS MODE IS SEQUENTIAL
000900                    FILE STATUS IS VarFile-Stat
001000                      .
001100 Data Division.
001200  File Section.
001300   FD VarFile
001400      BLOCK CONTAINS 1 TO 32763 CHARACTERS
001500      RECORD IS VARYING FROM 1 TO 32755 CHARACTERS
001600                DEPENDING ON VarRec-Len
001700      DATA RECORD IS VarFile-Rec.
001800   01 VarFile-Rec PIC X(32755).
001900  Working-Storage Section.
002000   01 VarRec-Len  PIC 9(4) BINARY.
002100   01 VarFile-Stat PIC XX.
002110   01 Eof-switch PIC X VALUE 'N'.
002120         88 end-of-file VALUE 'Y'.
002200  Procedure Division.
002300      OPEN INPUT VarFile
002400      IF VarFile-Stat NOT EQUAL '00'
002500         DISPLAY 'Open failed with status ' VarFile-Stat
002600         GOBACK
002700      END-IF
002800      PERFORM UNTIL end-of-file
002900        READ VarFile
003000           AT END
003010              SET end-of-file TO TRUE
003100           NOT AT END
003200              DISPLAY 'Record length was ' VarRec-len
003300              DISPLAY 'Record text was>' VarFile-Rec '<'
003310              DISPLAY 'File status was ' VarFile-Stat
003400        END-READ
003500      END-PERFORM
003600      CLOSE VarFile
003700      GOBACK
003800      .

Sitting in a boring hotel room I have not got my mainframe handy, but this program works
flawlessly on my thinkpad.  I think I can read any VB (and possibly VBS) file with it

HTH

with kind regards

Volker Bandke
(BSP GmbH)



Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?
On Tue, 29 Sep 1998 17:16:19, "Chris Osborne"

Quote:

> Now, you are probably, saying, this is a OUTPUT, not a read.  Right?  Of
> course, I don't have a source file with a massive number of variable records
> of differing kinds, so I had to create one.  If I can create one with one
> FD, you bet I can read one with one FD.

I think that if you ALLOCATE a VB file with a maxrecl of... oh.. 256
and try to read with the FD varying from 1 to 32752, you will get an
open error 39.

I think the contention (accurate I think) is that you HAVE to match
MAX reclen in the program with MAX physical recln of the VB file or it
won't work.



Sat, 17 Mar 2001 03:00:00 GMT  
 How Many COBOL Programs Does It Take To Change A Light Bulb?

Quote:

>On Tue, 29 Sep 1998 17:16:19, "Chris Osborne"

>> Now, you are probably, saying, this is a OUTPUT, not a read.  Right?  Of
>> course, I don't have a source file with a massive number of variable
records
>> of differing kinds, so I had to create one.  If I can create one with one
>> FD, you bet I can read one with one FD.

>I think that if you ALLOCATE a VB file with a maxrecl of... oh.. 256
>and try to read with the FD varying from 1 to 32752, you will get an
>open error 39.

>I think the contention (accurate I think) is that you HAVE to match
>MAX reclen in the program with MAX physical recln of the VB file or it
>won't work.

Thane,

Except, of course, that the JCL lrecl must be 4 bytes greater than the
program lrecl because of the Record Descriptor Word.

And no, I wouldn't expect a JCL lrecl of 256 to work if I had specified a
max program lrecl of 32752 (or any number > 256).  If that was the
contention, trying to find a way to do that, then I can only say I don't
know how to do that.

I thought Theo had finally decided that what he wanted to do was issue READs
against any length of record using only _one_ FD with only _one_ 01 level
record description under it.
I'm sorry if I misunderstood again.



Sat, 17 Mar 2001 03:00:00 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. lighting Ive done / do you know other (complex) lighting examples

2. *Light Bulb List Members* - humor

3. The light bulb goes on...

4. How many Ada programmers does it take to change a light bulb?

5. php.ini changes not taking

6. Changing DISPLAY takes effect?

7. X-Lock lights, changing - using the Kb controller.

8. Calling a non-COBOL program from a COBOL program on OS/390

9. Economical/cheap bicycle light? Re: Bicycle Lighting

10. Economical/cheap bicycle light? Re: Bicycle Lighting

11. Turn the lights of/Light behaviour

12. Changing date format when doing MySQL query?

 

 
Powered by phpBB® Forum Software