Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

reading COBOL Sequential output file (Easy Question)---Help 1

Status
Not open for further replies.

akita12

Programmer
Nov 25, 2003
5
US
I am reading a sequential file using a Visual Basic 6.0 Type Array. As I read each record from the cobol output Sequential file ---- the VB Sub will then insert a record into the db as I have the data put into the array with the correct space allocated from the cobol output file.


I am given the cobol sequential file layout.

I know how many characters to allow a
ID pic X(02)'''''2 right?
CATEGOREY pic X(01) etc''''1 right?

but what do I do with a
FLOORPLAN pic s99v99
and
FLOOR B pic s99v99 occurs 8
and
FLOOR C pic s(9) occurs 4
????

These are really confusing me and I cannot find that much research on it.

Thanks for any of your help
email me if my question is unclear or you want to talk further about the question.
Thanks in advance.

Jeff Fisher
Systems Engineering, Inc.


 
Hi akita12,

I can't say that i understood the cobol's file description. Can you copy/paste it from your source program?

Besides that, is it a cobol LINE sequential file? If yes, then it is a plain text file and you should be able to read it just like any other text file.

What exactly is your problem with the FLOOR fields?

Theophilos.
 
BTX802R-REC I beleive is a fixed line file
This is what I was given to know how many characters each field contains in the cobol output sequential file (BTX802R)
I fill the array with the data in the file.

016900 01 BTX802R-REC.'''''name of the file to read
017000 03 RC-KEY PIC X(14).
017100* RC-KEY(01:12) IS A PARCEL-NO
017200* RC-KEY(13:02) IS A HOUSE AND CAN BE "01" THRU "09".
017300 03 USE-CODE.
017400 05 USE-CAT PIC X(02).
017500 05 USE-OCCUPY PIC X(01).
017600 88 OWNER-OCCUPIED VALUE "1".
017700 88 RENTAL-OCCUPIED VALUE "2".
017800 88 BASEMENT-APT VALUE "3".
017900 88 MULTI-FAMILY-UNIT VALUE "4".
018000 88 CONDO VALUE "5".
018100 88 TOWN-HOUSE VALUE "6".
018200 88 FIVE-PLEX VALUE "7".
018300 88 OUT-BUILDING VALUE "8".
018400 05 FLOOR-STYLE PIC X(01).
018500 88 ONE-WITHOUT-BASEMENT VALUE "1".
018600 88 ONE-WITH-BASEMENT VALUE "2".
018700 88 TWO-WITHOUT-BASEMENT VALUE "3".
018800 88 TWO-WITH-BASEMENT VALUE "4".
018900 88 SPLIT-LEVEL VALUE "5".
019000 88 SPLIT-ENTRY VALUE "6".
019100 88 ONE-HALF-NO-BASE VALUE "7".
019200 88 ONE-HALF-WITH-BASE VALUE "8".
019300 88 SPLIT-STORY VALUE "9".
019400 05 USE-UNIT PIC X(02).
019500 88 DUPLEX VALUE "41".
019600 88 TRIPLEX VALUE "42".
019700 88 FOURPLEX VALUE "43".
019800 88 FIVEPLEX VALUE "70".
019900 88 SIXPLEX VALUE "44".
020000 88 DORMATORY VALUE "45".
020100 88 BASEMENT-RENTAL VALUE "30".
020200 03 PRINT-BYTE-R PIC X(02).
020300 03 KLASS PIC S9(4).
020400 03 YEAR-BUILT PIC S9(4).
020500 03 EFF-AGE PIC S9(4).
020600 03 COMPUTE-DATE PIC X(6).
020700 03 PCT-COMPLETE PIC S99V99.
020800 03 RES-VALUE PIC S9(9).
020900 03 GARAGE-VALUE PIC S9(9).
021000 03 CARPORT-VALUE PIC S9(9).
021100 03 FLOOR-B PIC S99V99 OCCURS 8.
021200 03 FLOOR-L1 PIC S99V99 OCCURS 8.
021300 03 FLOOR-L2 PIC S99V99 OCCURS 8.
021400 03 FLOOR-A PIC S99V99 OCCURS 8.
021500 03 OI-VALUE PIC S9(9).
021600 03 BASE-TOT-R PIC S9(4).
021700 03 FLOOR-1-R PIC S9(4).
021800 03 FLOOR-2-R PIC S9(4).
021900 03 ATTIC-TOT-R PIC S9(4).
022000 03 GARAGE-ARRAY OCCURS 3.
022100 05 GRG-TYPE PIC X(02).
022200 05 GRG-AREA PIC S9(9).
022300 05 GRG-DIM PIC S9(4) OCCURS 2.
022400 03 FEAT-ARRAY OCCURS 50.
022500 05 DETAIL-QUANT PIC S9(9).
022600 05 DETAIL-DESC PIC X(40).
022700 03 OTH-IMP-ARRAY OCCURS 15.
022800 05 OTH-DESC PIC X(10).
022900 03 EVEN-BYTE-R PIC X(01).
 
I won't get too detailed but will just try to answer your basic questions. It seems that al you really want to know is how many characters to allow for the fields you are reading. That's all we'll address for now.

1. You are right about the length of PIC X fields. Those are alphanumeric data fields and the length is equal to the number in parentheses. There is an option to leave off the parentheses and code as many X's as there are characters. So, PIC XXX would take 3 bytes, PIC X(05) is 5 bytes, etc.

2. The items you show such as PIC S99V99 are numeric fields. They contain a sign (S) and an assumed decimal position (V). With the definitions that you have in your sample layout, the sign is in the zone portion of the rightmost byte so it does not take any extra space. The V designates an assumed decimal. Therefore it is not really there. It is used in calculations in a COBOL program to align decimals. So, PIC S99V99 takes 4 bytes (Count the 9's just like you would for PIC X). Could see it as S9(02)V9(02). Again, it is 4 bytes long.

3. The OCCURS clause creates an array. So, PIC X(02) OCCURS 4 says there are 4 fields defines and each one takes 2 bytes. So in this case, 8 bytes are needed. You can also have OCCURS with PIC 9. So, PIC S9(03) OCCURS 5 takes 15 bytes.
 
That is a great reply.

You explained perfectly
1 more question? easy for someone of YOUR cobol expertise

03 GARAGE-ARRAY OCCURS 3.
05 GRG-TYPE PIC X(02).
05 GRG-AREA PIC S9(9).
05 GRG-DIM PIC S9(4) OCCURS 2.

how it states '022000 03 GARAGE-ARRAY OCCURS 3.'
with no pic and then breaks into a sub categorey
with seperate pics??


This one two
03 SECTIONS.
05 SECTION1 PIC X.
05 SECTION2 PIC X.

QUESTION??
In both of these--
Which part of this counts and which does not.

Thanks
 
[tt]
03 GARAGE-ARRAY(1).
05 GRG-TYPE(1) PIC X(02). *> 2 bytes
05 GRG-AREA(1) PIC S9(9). *> 9 bytes
05 GRG-DIM(1,1) PIC S9(4). *> 4 bytes
05 GRG-DIM(1,2) PIC S9(4). *> 4 bytes
03 GARAGE-ARRAY(2).
05 GRG-TYPE(2) PIC X(02). *> 2 bytes
05 GRG-AREA(2) PIC S9(9). *> 9 bytes
05 GRG-DIM(2,1) PIC S9(4). *> 4 bytes
05 GRG-DIM(2,2) PIC S9(4). *> 4 bytes
03 GARAGE-ARRAY(3).
05 GRG-TYPE(3) PIC X(02). *> 2 bytes
05 GRG-AREA(3) PIC S9(9). *> 9 bytes
05 GRG-DIM(3,1) PIC S9(4). *> 4 bytes
05 GRG-DIM(3,2) PIC S9(4). *> 4 bytes

03 SECTIONS.
05 SECTION1 PIC X. *> 1 byte
05 SECTION2 PIC X. *> 1 byte
[/tt]
As shown, there are three GARAGE-ARRAY fields, each occupying 21 bytes. There are three GRG-TYPE fields, each occupying the first two bytes of each GARAGE-ARRAY. There are three GRG-AREA fields, each occupying bytes 3-11 of each GARAGE-ARRAY. The "S" does not take up a byte. There are six GRG-DIM fields; the 1st, 3rd, and 5th occupy bytes 14-17 of each GARAGE-ARRAY; the 2nd, 4th, and 6th occupy bytes 18-21 of each GARAGE-ARRAY. Again, the "S" does not take up a byte.

The SECTIONS field occupies two bytes. SECTION1 occupies the first byte of SECTIONS, and SECTION2 occupies the second byte.
 
I do not see the 21
I only count 19
2+9+4+4 = 19

This below does not make sense to me at all
please explain if you can-
I am an experienced developer, but this is my first day attempting to understand cobol

There are six GRG-DIM fields; the 1st, 3rd, and 5th occupy bytes 14-17 of each GARAGE-ARRAY; the 2nd, 4th, and 6th occupy bytes 18-21 of each GARAGE-ARRAY. Again, the "S" does not take up a byte.

1st 3rd and 5th what?? etc, etc




If the 'GRG-DIM PIC S9(4) OCCURS 2'
because it occurs 2 then that is only a 4 plus a 4 ??

if your 21 is right. is this going to be
three fields for garage each 21 bytes long

SO.....
garage_Type As String * 21
garage_area As String * 21
garage_dim As String * 21

for my VB 'Read IN' program





 
Webrabbit misspoke on the 21 bytes. Each is 19 bytes.

An item without a PICture clause is a group item. Group Items are similar to C Structures or VB user defined types. They provide a convenient way to name one or more contiguous variables that can be themselves group items or elementary items (i.e. with a PIC).

GARAGE-ARRAY group item which OCCURS 3 times (i.e. is an array).

You will likely have fits with the signs on the numeric items. It may not be clear from the above that the sign digit is overpunched in the last byte. That means the last byte of these numeric fields will be an alphabetic character! (e.g. {, A, B, ..., I represent +0, +1, ..., +9; }, J, K, ..., R represent -0, -1, ..., -9). Search the FAQ for information about signed fields if you need more information.

Regards.

Glenn
 
So speaking in database terms? field terms

This garage scenerio ''GARAGE-ARRAY' (OCCURS 3).' is referring to 3 seperate fields
I will name the fields garage_descr_1, garage_descr_2, garage_descr_3

garage_descr_1 is really broken down into 4 'sub fields'
like this
1 2 3 4
GRG_Type x(02)|GRG_Area s9(9)|GRG_DIM s9(4)|GRG_DIM s9(4)

garage_descr_2 the same way
garage_descr_3 the same way

The reason the cobol uses this array is for display purposes.
They put the field into an array and used the 'diced up' array every time they want to display anything about the garage

Is my logic correct? Database speaking







 
Your description of how the GARAGE-ARRAY is broken into its components is accurate. But COBOL does not use the array for display purposes. The array is used so you can process any of the 3 different GARAGE-ARRAY sets of data without having unique code for each. You just need to supply a subscript to have the logic reference the correct occurrence in the array. It saves duplicate logic by defining the data as an array.
 
You're right 3gm. I miscounted. But the internal representation of the "overpunch" is different on different platforms.

Many languages do not allow arrays of structures or arrays within structures, so COBOL can be confusing to those not familiar with the concept. Also, I think the "group" is unique to COBOL. It is like a structure in the way the data is allocated, but group operations are not like structure operations at all.

I think akita12 needs to read an introduction to COBOL.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top