Re: Cobol problem (INPUT File Format)

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 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

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 exis
ts
as a physical file.

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

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

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

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

***

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

Until you can answer my questions about the physical file you are working wi
th
for input, there is really no way we are going to be able to help you.  If y
ou
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(??).
>
>
>
>

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

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... 
>
>

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 corre
ct
(matching the ACTUAL physical file layout) you simply will NOT get your READ
s 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> 
>
>

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

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