Cobol - Re: Cobol problem (INPUT File Format)

Author

Re: Cobol problem (INPUT File Format)

Rick

2005-02-08, 3:55 pm

Hi,
Pertaining to my earlier posting, here's basically how the
INPUT file look like. Just a format only below. Basically it's a
huge file with many fields and with 'redefines', 'occurs' all
that declare in the file.

Take note that there are
- REDEFINES
- OCCURS
- REDEFINES within a REDEFINES
use in the input file.

But my OUTPUT file is basically a flat file declaration only.

That's y not sure what the problem that's causing my o/p of
some of the field to contain prev input values when indeed
it's suppose to be blank.

Actually, my pgm correctly pick the record to be extracted(based on
condition), just that some fields populate wrong values, when it's
supposed to be blanks. Weird.

For the code, refer to my initial posting. :-)
Tks in advance for advise :-)

INPUT File <FORMAT>
=================
01 TRN-HEADER.

05 TRN-xxxx-xxx PIC X(50).

05 TRN-DTE PIC 9(06).

05 FILLER PIC X(1471).

01 TRN-RECORD REDEFINES TRN-HEADER. <==**

05 TRANS-KEY.

10 xxxxx PIC X(??).

10 xxxxx PIC X(??).

10 xxxxx PIC X(??).

05 TRN-DETLS PIC X(1260). <==Take note

05 TRN-CR-DETLS REDEFINES TRN-DETLS. <==**

10 xxxxx PIC X(??).

10 xxxxx PIC 9(??).

05 TRN-DR-DETLS REDEFINES TRN-DETLS.

10 xxxxx PIC X(??).

10 xxxxx OCCURS 2. <===**

15 xxxxx PIC X(??).

15 xxxxx PIC X(??).

05 TRN-INT-DETLS REDEFINES TRN-DETLS.

10 xxxxx PIC X(??).

10 xxxxx PIC 9(??).

10 xxxxx REDEFINES RMK-FLD-1 PIC X(??). <==**

10 xxxxx PIC X(??).

10 xxxxxx REDEFINES RMK-FLD-2 PIC X(??).

10 xxxxx PIC 9(??).

Donald Tees

2005-02-08, 3:55 pm

Rick wrote:
> Hi,
> Pertaining to my earlier posting, here's basically how the
> INPUT file look like. Just a format only below. Basically it's a
> huge file with many fields and with 'redefines', 'occurs' all
> that declare in the file.
>
> Take note that there are
> - REDEFINES
> - OCCURS
> - REDEFINES within a REDEFINES
> use in the input file.
>

Remove the 01 level redefines clauses. Redefines is implictit with FD
records ... I would have expected it to give you a compile error.

Donald

William M. Klein

2005-02-08, 3:55 pm

You still haven't answered my questions. I don't want to know how you have
defined the file in your program. I want to know how the file ACTUALLY exists
as a physical file.

Again, simply tell me WHICH of the following 3 descriptions matches the physical
input file

1) All records are PHYSICALLY the same length - but some of them only use 700
bytes - and have trailing spaces

2) Some physical records are 700 bytes long and some physical records are 1500+
bytes long

3) Some records are 700 bytes long; some records are 1500+ bytes long; and some
physical records are any length in-between.

***

Your use of the term "flat file" and "file contains fields" sound like you don't
understand how physical files exist.

Until you can answer my questions about the physical file you are working with
for input, there is really no way we are going to be able to help you. If you
don't understand my questions, try and get a more experienced programmer in you
shop to help you.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick" <leng1@bigfoot.com> wrote in message
news:cuagbc$7j0$1@mawar.singnet.com.sg...
> Hi,
> Pertaining to my earlier posting, here's basically how the
> INPUT file look like. Just a format only below. Basically it's a
> huge file with many fields and with 'redefines', 'occurs' all
> that declare in the file.
>
> Take note that there are
> - REDEFINES
> - OCCURS
> - REDEFINES within a REDEFINES
> use in the input file.
>
> But my OUTPUT file is basically a flat file declaration only.
>
> That's y not sure what the problem that's causing my o/p of
> some of the field to contain prev input values when indeed
> it's suppose to be blank.
>
> Actually, my pgm correctly pick the record to be extracted(based on
> condition), just that some fields populate wrong values, when it's
> supposed to be blanks. Weird.
>
> For the code, refer to my initial posting. :-)
> Tks in advance for advise :-)
>
>
> INPUT File <FORMAT>
> =================
> 01 TRN-HEADER.
>
> 05 TRN-xxxx-xxx PIC X(50).
>
> 05 TRN-DTE PIC 9(06).
>
> 05 FILLER PIC X(1471).
>
>
>
>
>
> 01 TRN-RECORD REDEFINES TRN-HEADER. <==**
>
> 05 TRANS-KEY.
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxx PIC X(??).
>
>
>
>
>
> 05 TRN-DETLS PIC X(1260). <==Take note
>
> 05 TRN-CR-DETLS REDEFINES TRN-DETLS. <==**
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxx PIC 9(??).
>
>
>
> 05 TRN-DR-DETLS REDEFINES TRN-DETLS.
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxx OCCURS 2. <===**
>
> 15 xxxxx PIC X(??).
>
> 15 xxxxx PIC X(??).
>
>
>
> 05 TRN-INT-DETLS REDEFINES TRN-DETLS.
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxx PIC 9(??).
>
> 10 xxxxx REDEFINES RMK-FLD-1 PIC X(??). <==**
>
> 10 xxxxx PIC X(??).
>
> 10 xxxxxx REDEFINES RMK-FLD-2 PIC X(??).
>
> 10 xxxxx PIC 9(??).
>
>
>
>

Rick

2005-02-09, 8:55 am

Hi Donald,
Just a notice.
I can't just remove the 01 from the 'existing' INPUT file that is also used
by many programs.

"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:ws4Od.3034$504.397597@news20.bellglobal.com...
> Rick wrote:
>
> Remove the 01 level redefines clauses. Redefines is implictit with FD
> records ... I would have expected it to give you a compile error.
>
> Donald

Rick

2005-02-09, 8:55 am

Info as below for

'INPUT' file :

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

ORGANIZATION : VSAM KSDS - VARIABLE

RECORD SIZE : 700 - 1527 BYTES

- The format of the input file, can see my initial posting

based on above subject :-) .

- Basically, all records are the same length.

- The record info store this way.Assume the input file

comprise of info on CR, DR,INTEREST transaction and if

the transaction is on CR , the input file for that record

will be populated for fields of those CR transaction,

wherelse the rest of those fields for DR and INTEREST

of the same record will be blanks. (inside this input field,

there are OCCURS, REDEFINES etc used based on the copybook)

- Of course, certain fields are mandatory for ALL records, like

userid, trans reference, date entered, time entered, etc..

****

Basically, my definition of 'flat file' refer to my 'o/p'

file, with a single declaration length (no individual

fieldname declaration).

When mentioned 'file contains field', what I am trying to

say is that there are certain values being written to the o/p

file of certain columns, though there's really didn't exist a

'fieldname' there in the o/p file, as it's basically a flat file

for o/p.

Not sure how I should better elaborate.. :-)

Tks William :-)

"William M. Klein" <wmklein@nospam.netcom.com>
> You still haven't answered my questions. I don't want to know how you
> have defined the file in your program. I want to know how the file
> ACTUALLY exists as a physical file.
>
> Again, simply tell me WHICH of the following 3 descriptions matches the
> physical input file
>
> 1) All records are PHYSICALLY the same length - but some of them only use
> 700 bytes - and have trailing spaces
>
> 2) Some physical records are 700 bytes long and some physical records are
> 1500+ bytes long
>
> 3) Some records are 700 bytes long; some records are 1500+ bytes long; and
> some physical records are any length in-between.
>
> ***
>
> Your use of the term "flat file" and "file contains fields" sound like you
> don't understand how physical files exist.
>
> Until you can answer my questions about the physical file you are working
> with for input, there is really no way we are going to be able to help
> you. If you don't understand my questions, try and get a more experienced
> programmer in you shop to help you.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Rick" <leng1@bigfoot.com> wrote in message
> news:cuagbc$7j0$1@mawar.singnet.com.sg...
>
>

William M. Klein

2005-02-09, 8:55 am

Rick,
PLEASE - answer my question.

You have now told us (for the first time) that the input is a VSAM KSDS file
(which to non-IBM people is an INDEXED file).

In this same note you say

"VSAM KSDS - VARIABLE
RECORD SIZE : 700 - 1527 BYTES"

and

"Basically, all records are the same length"

***

If you do an IDCAMS LISTCAT ALL on the file, then

If AVGLRECL equals MAXLRECL
the PHYSICAL KSDS file is "fixed length"

If AVGLRECL does NOT equals MAXLRECL
then the PHYSICAL KSDS file is VARIABLE

If the former, then define (in the FD) the file with
RECORD CONTAINS "MAXLRECL"

If the latter, then define (in the FD) the file with

Record VARYING IN SIZE from 700 to "MAXLRECL" size
Depending ON WS-item

Do *not* use the
"RECORD CONTAINS n TO nn" clause for a variable length KSDS file - unless
you have some other way of determining what size record you have.

***

Once again, until/unless you get your Select/Assign and FD definitions correct
(matching the ACTUAL physical file layout) you simply will NOT get your READs to
work correctly.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick" <leng1@bigfoot.com> wrote in message
news:cucldg$9jd$1@mawar.singnet.com.sg...
> Info as below for
>
> 'INPUT' file :
>
> ===============
>
> ORGANIZATION : VSAM KSDS - VARIABLE
>
> RECORD SIZE : 700 - 1527 BYTES
>
>
>
> - The format of the input file, can see my initial posting
>
> based on above subject :-) .
>
>
>
> - Basically, all records are the same length.
>
>
>
> - The record info store this way.Assume the input file
>
> comprise of info on CR, DR,INTEREST transaction and if
>
> the transaction is on CR , the input file for that record
>
> will be populated for fields of those CR transaction,
>
> wherelse the rest of those fields for DR and INTEREST
>
> of the same record will be blanks. (inside this input field,
>
> there are OCCURS, REDEFINES etc used based on the copybook)
>
>
>
> - Of course, certain fields are mandatory for ALL records, like
>
> userid, trans reference, date entered, time entered, etc..
>
>
>
> ****
>
> Basically, my definition of 'flat file' refer to my 'o/p'
>
> file, with a single declaration length (no individual
>
> fieldname declaration).
>
>
>
> When mentioned 'file contains field', what I am trying to
>
> say is that there are certain values being written to the o/p
>
> file of certain columns, though there's really didn't exist a
>
> 'fieldname' there in the o/p file, as it's basically a flat file
>
> for o/p.
>
>
>
> Not sure how I should better elaborate.. :-)
>
>
>
> Tks William :-)
>
>
>
>
>
>
> "William M. Klein" <wmklein@nospam.netcom.com>
>
>

James J. Gavan

2005-02-09, 3:55 pm

Rick wrote:
> Info as below for
>
> 'INPUT' file :
>
> ===============
>
> ORGANIZATION : VSAM KSDS - VARIABLE
>
> RECORD SIZE : 700 - 1527 BYTES
>
>
>
> - The format of the input file, can see my initial posting
>
> based on above subject :-) .
>
>
>
> - Basically, all records are the same length.
>
>
Well at least we know you are working on a mainframe. The above phrase
just DOESN'T JIVE. There are 'no basicallys' in programming, either true
or false. Either your have FIXED or you have VARIABLE records.

As you are working at a mainframe site ASK ONE OF YOUR PEERS, as
somebody else recently suggested. If you are afraid to admit you don't
know, then eventually you will finish up in the doggy doo, and your
career will go down the tubes. Try and pick a fellow worker with a
sympathetic ear - we all learn from one another. And no matter how many
decades we have been at the 'game', we all had to go through a learning
cycle - and can still learn new things !

Jimmy, Calgary AB

James J. Gavan

2005-02-15, 8:55 pm

Sponsored Links