I have a 7-digit packed-decimal field on my file. How can I define data items that would extract/separate these 7 digits?
For example I want to have the first two digits in one data item and the other digits in another, so I can manipulate them later.
In some other languages one of the things which may be common would be to "divide by a multiple of 10", an appropriate multiple, of course.
However, don't ever consider that with COBOL. A "divide" is "expensive".
05 input-packed-decimal
PACKED-DECIMAL PIC 9(7).
Then:
05 FILLER
REDEFINES input-packed-decimal.
10 ipd-split-two-and-five
PACKED-DECIMAL PIC 99V9(5).
01 two-digits PIC 99.
01 five-digits PIC 9(5).
01 FILLER
REDEFINES five-digits.
05 five-digits-as-decimals PIC V9(5).
MOVE ipd-split-two-and-five TO two-digits
five-digits-as-decimals
Then you are able to use two-digits and five-digits for whatever you want.
Another way:
01 ws-input-seven PIC 9(7).
01 FILLER
REDEFINES ws-input-seven.
05 two-digits PIC 99.
05 five-digits PIC 9(5).
MOVE input-packed-decimal TO ws-input-seven
The first way will also work for signed source fields (just put an S in the appropriate place in each PICture clause).
The second will not work with signed fields, because the source sign will no propagate to the two-digits field because the MOVE is not even aware that there is such a field.
Take care when REDEFINESing PACKED-DECIMAL or BINARY fields (on an IBM Mainframe, these can also have USAGE COMP-3 and COMP/COMP-4/COMP-5). Always, when defining with the same, or similar, USAGE, define the same number of digits. For a REDEFINES field the compiler will always assume that you know what you are doing, so it will not do any "truncation of source" for you. So you have to ensure that you are not, explicitly or implicitly, expecting truncation of source when you use fields subordinate to a REDEFINES.
To get the second digit, don't ever do this:
05 FILLER
REDEFINES input-packed-decimal.
10 ignore-one-use-2nd-next-five
PACKED-DECIMAL PIC 9V9(5).
To get the second digit, use PACKED-DECIMAL PIC 99V9(5) as before, but define the receiving field with only one digit position. The compiler will happily then generate code to do the truncation you expect.
If you are "unable to use REDEFINES" you'll have to create a new field in the WORKING-STORAGE with the same characteristics as your input field, and use that.
The data-names I've used here are solely for this general explanation. Use good, descriptive, names to your task. If the first two digits are part-type, and the last five are part-number, make sure that is clear fro your naming.
Don't name them "Var(n)" or similar and don't give them names which are misleading.
01 the-array.
03 filler pic x(02) value '00'.
03 filler pic x(02) value '01'.
03 filler pic x(02) value '02'.
and so on, until
03 filler pic x(02) value 'FF'.
01 two-array redefines the-array.
03 harry occurs 256 pic x(02).
91 sub1.
03 filler pic x(01) value low-values.
93 sub1-byte2 pic x(01).
01 sub2 redefines sub1 comp.
01 pd pic x(04).
01 pub pic 9(04).
01 eggs.
03 eggs1 pic x(01).
03 eggs2 pic x(01).
perform varying pub
from 1 by 1
until pub > 4
move pd(pub:1) to sub1-byte2
move harry(sub2 + 1) to eggs
display eggs1 egg2
end-perform.
So an array of 256 2 byte fields with values of '00' thru 'FF'.
step thru the 4 byte field that holds your packed decimal field.
use each byte as a subscript into the array (add 1 to ensure '00' points to first field in array).
2 byte field pointed to has the values of the 2 nibbles that represent that byte from the packed decimal field.
the right hand nibble of the fourth byte in the packed decimal field is for the sign.
Related
I have a very simple COBOL code here that has a given input data and output data. The problem is that, it shows an error on line 60 which is the MOVE STUD-AGE TO AGE-OUT. and everytime I run OpenCOBOLIDE, I always get and error which is:
libcob: test.cob: 60: 'STUD-AGE' not numeric: ' '
WARNING - Implicit CLOSE of STUDENT-OUT ('C:\STUD-OUT.DAT')
WARNING - Implicit CLOSE of STUDENT-IN ('C:\STUD-IN.DAT')
And I don't know exactly what's wrong with it. Here is supposedly the input file I created:
----5---10---15---20---25---30---35---40--
00-123345 ALISON MARTIN WOLF 1912056
00-789012 KEN DENNIOS ROME 1914156
00-345678 JACK ADRIAN TOCKSIN 1622234
00-901234 EJHAYZ ALONEY 2045645
00-567890 CHARLES JOHN GUINNIVER 1813243
00-123457 JEAN MICHAEL YARTER 2034253
Here's the code to it:
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT STUDENT-IN ASSIGN TO "C:\STUD-IN.DAT".
SELECT STUDENT-OUT ASSIGN TO "C:\STUD-OUT.DAT".
DATA DIVISION.
FILE SECTION.
FD STUDENT-IN.
01 STUD-REC.
02 STUD-NO PIC X(10).
02 STUD-NAME PIC X(25).
02 STUD-AGE PIC 99.
02 STUD-ALLOWANCE PIC 999V99.
FD STUDENT-OUT.
01 PRINT-REC PIC X(80).
WORKING-STORAGE SECTION.
01 HDG-1.
02 FILLER PIC X(20) VALUE SPACES.
02 FILLER PIC X(22) VALUE "WILLOW PARK UNIVERSITY".
02 FILLER PIC X(14) VALUE " OF MADAGASCAR".
01 HDG-2.
02 FILLER PIC X(9) VALUE SPACES.
02 FILLER PIC X(14) VALUE "STUDENT NUMBER".
02 FILLER PIC X(8) VALUE SPACES.
02 FILLER PIC X(12) VALUE "STUDENT NAME".
02 FILLER PIC X(15) VALUE SPACES.
02 FILLER PIC X(3) VALUE "AGE".
02 FILLER PIC X(8) VALUE SPACES.
02 FILLER PIC X(9) VALUE "ALLOWANCE".
01 PRINT-LINE.
02 FILLER PIC X(9) VALUE SPACES.
02 SNO-OUT PIC X(10).
02 FILLER PIC X(12) VALUE SPACES.
02 SNAME-OUT PIC X(25).
02 FILLER PIC X(2) VALUE SPACE.
02 AGE-OUT PIC Z9.
02 FILLER PIC X(9) VALUE SPACES.
02 ALL-OUT PIC ZZZ.99.
01 E-O-F PIC XXX VALUE "NO".
PROCEDURE DIVISION.
OPEN INPUT STUDENT-IN
OUTPUT STUDENT-OUT.
WRITE PRINT-REC FROM HDG-1 BEFORE 1 LINE.
WRITE PRINT-REC FROM HDG-2 AFTER 2 LINES.
MOVE SPACES TO PRINT-REC.
WRITE PRINT-REC AFTER 1 LINE.
PERFORM READ-RTN UNTIL E-O-F = "YES".
PERFORM CLOSE-RTN.
READ-RTN.
READ STUDENT-IN AT END MOVE "YES" TO E-O-F.
MOVE STUD-NO TO SNO-OUT.
MOVE STUD-NAME TO SNAME-OUT.
MOVE STUD-AGE TO AGE-OUT.
MOVE STUD-ALLOWANCE TO ALL-OUT.
WRITE PRINT-REC FROM PRINT-LINE AFTER 1 LINE.
CLOSE-RTN.
CLOSE STUDENT-IN, STUDENT-OUT.
STOP RUN.
What I want to achieve is just to output the file correctly but the error only inputs the HDG-1 and then the rest blank.
To answer your question: COBOL accept numeric data however you define it.
So for "text data" (as long as it isn't UTF-16 or another multibyte encoded file) PIC 99 (which says "two digits in the default USAGE DISPLAY - so one byte per digit) is perfectly fine.
As with every other language: "never trust input data" is something I can recommend. For example: someone could run this program with a file that was saved with an UTF-8 encoded character in the name and then it "looks" right but the code has an unexpected shift in its data. For COBOL things like FUNCTION TEST-NUMVAL(inp) [ignores spaces and allows decimal-point] or IS NUMERIC (strict class test) can be useful.
Using data-check you could for example also skip empty lines or leading/trailing extra data (temporary rulers, headline, summary, ...).
For the actual problem:
It looks like you feed the program with a "common" text file, but you actually did not specify this so your COBOL implementation uses the default SEQUENTIAL. Because of the missing check of the input data you did not spot this directly.
To align expectations and code:
SELECT STUDENT-IN ASSIGN TO "C:\STUD-IN.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
SELECT STUDENT-OUT ASSIGN TO "C:\STUD-OUT.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
I am using CopybookInputFormat on git https://github.com/tmalaska/CopybookInputFormat/ to generate hive table definition from COBOL copybook. My copybook has many Fillers (duplicate columns)
but it looks like JRecord is not handling duplicate column name correctly.
For below copybook, when I iterate columns, JRecord only prints second Filler and ignores first filler.
05 Birth-day PIC X(002)
05 Filler PIC X(008)
05 Birth-Month PIC X(002)
05 Filler PIC X(008)
05 Birth-year PIC X(004)
Does anyone have any solution for this? I know JRecord 0.80.6 onward is handling duplicate columns, but method getUniqueField("FIRST-NAME", "PRESIDENT") needs a group name.. but what if group has duplicate columns?
You should not need to import a Filler. In Cobol, a Filler can not be directly accessed. In Cobol a Filler say's Ignore this Field (or access it by another method).
A Cobol-Copybook is like a mask over a block of memory; A filler is used to skip some memory.
Data !##........##........## (# - accessible bytes; . - inaccessible bytes)
^ ^ ^
! ! !
Birth-day ---+ ! !
Filler ! !
Birth-Month -------------+ !
Filler !
Birth-year -----------------------+
A filler can be used to:
Mask fields that are no longer used.
Used mask data in a redefines
Create a simplified version of a copybook when you do not need all the fields
Initializing an output field i.e
05 report-Birth-date
10 dd pic 99.
10 filler pic '/'.
10 mm pic 99.
10 filler pic '/'.
10 yyyy pic 9999.
setting up Table data
05 codes.
10 code occurs 5 pic 99.
05 filler redefines codes pic x(10)
value '0204050612'.
I would ask the Cobol specialists where you work what is going on ???. Possible answers could be:
The filler data may not be needed.
You should be using a different more complicated Copybook.
The copybook should be updated with the Fillers given real names.
I need to make a table out of the data structure below because I am not certain how many records that are each one line long will be in my input file. If I can make a table then I will be able to loop through them at a later time which is what I need to be able to do.
**Question: How to make a table out of the data structure before?
Part B: An array in Cobol is an OCCURS 100 TIMES
01 PRECORD.
05 JE.
10 NE PIC X(6) VALUE SPACES.
10 NM PIC X(2) VALUE SPACES.
05 FILL1 PIC X(16) VALUE SPACES.
05 TM PIC X(7) VALUE SPACES.
05 FILL2 PIC X(6) VALUE SPACES.
05 TT PIC X(7) VALUE SPACES.
05 FILL3 PIC X(13) VALUE SPACES.
05 TTY PIC X(10) VALUE SPACES.
05 FILL4 PIC X(13) VALUE SPACES.
01 PRECORD.
02 table-counter <-- this is used to hold the number of records
02 tTable occurs 300 times. <-- creates a table with three hundred occurences
05 JE.
10 NE PIC X(6) VALUE SPACES.
10 NM PIC X(2) VALUE SPACES.
05 FILL1 PIC X(16) VALUE SPACES.
05 TM PIC X(7) VALUE SPACES.
05 FILL2 PIC X(6) VALUE SPACES.
05 TT PIC X(7) VALUE SPACES.
05 FILL3 PIC X(13) VALUE SPACES.
05 TTY PIC X(10) VALUE SPACES.
05 FILL4 PIC X(13) VALUE SPACES.
The code above is update with how I think that table should look. The table has to have a counter at the top and then under than it will have to have a occur and how many times the table should occur.
The question that I was asking was how do you make a table like above actually a table I did not know that you had to create an Occurs and then put everything below that level of the occurs.
01 mytable.
02 counter...
02 tablevar occures 200 times.
05 var...
05 var2..
I just was not sure of the structure of a Cobol table. My question is what was the format of a Cobol data structure?
Your table-counter will need a PICture.
What PICture? Opinions vary.
There are three numeric formats which are useful for this, binary, packed-decimal, and display-numeric.
nn table-counter COMP/COMP-4/BINARY/COMP-5 PIC 9(4).
nn table-counter COMP-3/PACKED-DECIMAL PIC 9(3).
nn table-counter PIC 9(3).
The most efficient definition will be a binary one. If you use packed-decimal, the compiler will generate code to convert it to binary when used in comparison with anything you use for subscripting (except literals). When using display-numeric, the compiler will generate code to first convert to packed-decimal, then to binary.
Do these things matter with the speed of machines these days? Well, if they don't matter, may as well be efficient, but opinions do vary.
What size for the PICture? 9(4) for binary allows up to 9999 as a maximum value. You can code 999, but it does not give you much advantage (can't limit it to 300), so I go for optimal for the size (for a packed-decimal (COMP-3) it would be 999, as you don't get a fourth digit for nothing). Same if using display-numeric. Again, opinions vary.
If those are records, as Magoo has pointed out, you can't just add the count to the beginning of the record. You can't keep your table in the FILE SECTION under and FD. It will need to go into the WORKING-STORAGE SECTION.
Then there is the problem of keeping two structures "in step" for where they should match each other.
You probably have a copybook for the record-layout. The best is if you can parameterise the names in the copybook, so that you can use REPLACING on the COPY statement, allowing you to use the same copybook for the two different purposes. It would then be important that the copybook does not contain an 01-level. Again opinions vary on the inclusion of 01s in copybooks, but you may get lucky.
Which, given all the opinion, gets us to "well, what do I do?". What you do is the way they do it at your site. There should be documentation of local standards. This may not cover everything, you may have to seek the opinions of colleagues. If you all code in about the same way, it makes the code easier to understand.
Personally, I'd declare table-counter as a 77-level with a PIC 9(03). And you really should remove the VALUE clauses. Of course, this would need to be a WORKING-STORAGE entry, not an FD since the table isn't on the file. Other than that, what you've dome appears valid - but it's difficult to see what question you are asking.
I'm editing some source code for my college Transaction Processing course. We're working with COBOL/CICS, and the program is a video tape rental system. We have a list of changes to make, and one item has me stuck (it's been since Fall semester of 2010 since I took the COBOL course, so unfortunately I'm far more rusty than I should be). There is a "customer maintenance" section, in which the user can add new customers. One of the items for a new customer is the zip code, and as it stands it will take any input as valid input, but we need to make it accept only numeric values (which I do know how to do) as well as a specific format: Either '12345', '123456789', or '12345-6789', and should only write to the record as '12345' or '12345-6789'. Anything else, such as '1234' or 12345-6' will result in an error. How do I check these fields for the proper format?
Since the valid data format is fixed, it is easy.
05 nice-name-for-zip-code pic x(10).
05 filler redefines nice-name-for-zip-code.
10 simple-zip-first-part pic x(5).
10 simple-zip-last-part pic x(5).
88 simple-zip-last-part-valid value space.
05 filler redefines nice-name-for-zip-code.
10 complex-zip-first-part pic x(5).
10 complex-zip-separator pic x.
88 complex-zip-separator value "-".
10 complex-zip-last-part pic x(4).
05 filler redefines nice-name-for-zip-code.
10 long-zip-first-part pic x(9).
10 long-zip-last-part pic x.
88 long-zip-last-part-valid value space.
if ( simple-zip-first-part numeric )
and ( simple-zip-last-part-valid )
....
if ( complex-zip-first-part numeric )
and ( complex-zip-separator-valid )
and ( complex-zip-last-part numeric )
....
if ( long-zip-first-part numeric )
and ( long-zip-last-part-valid )
....
If any of the IFs is true, you have a valid format. Otherwise, invalid.
A different approach might be to let CICS BMS support do most of the
validation and editing for you. This assumes you are using a 3270 type
terminal with CICS (which is probably the case)
Try setting the Zip Code up as a group field on the BMS map. This has the effect
of creating a single input field with multiple parts to it.
Your BMS Map definition would look something like:
ZIP1 DFHMDF POS=(2,1),LENGTH=5,GRPNAME=ZIP,ATTRB=(UNPROT,NUM)
SEP DFHMDF POS=(2,6),LENGTH=1,GRPNAME=ZIP,ATTRB=(ASKIP,NORM),INITIAL='-'
ZIP2 DFHMDF POS=(2,7),LENGTH=5,GRPNAME=ZIP,ATTRB=(UNPROT,NUM),JUSTIFY=(LEFT,BLANK)
The Zip code will appear at the beginning of line 2 (POS=(2..)). It will have a 5 digit input
field (ZIP1) for the first part of the Zip Code, followed by a hard coded input protected
dash (SEP) and another left justified 5
digit blank filled input field (ZIP2) for the last part of the Zip code.
From this point on, BMS will force the user to enter 5 digits into the first part of the Zip Code,
cannot touch the dash and optionally enter zero to 5 digits in the second part of
the input field. None of these fields will accept non-numeric data (except the SEP, which is input protected)
When you retrieve the data from the screen all you need to do is check to see
if ZIP2 is numeric to figure out if a long or short Zip code was entered. If
a long Zip, then store the whole thing, if short, only store ZIP1.
You could also use the CICS command BIF DEEDIT, which will remove non-numeric chars, the minus passes that test. After that, test for a length of 5 or 10.
Or, you could use an 88 like this:
01 Zip-Validation-Field.
02 filler pic x(5).
88 Zip-Valid value '00000' thru '99999'.
02 filler pic x(5).
88 Zip-plus-4-valid value '-0000' thru '-9999'.
And test with:
If Zip-Valid and Zip-plus-4-valid...
You can use MOVE CORR
01 TX-ZIPCODE PIC X(08) VALUE ' - '.
01 TX-ZIPCODE-R REDEFINES TX-ZIPCODE.
03 ZIPCODE-P1 PIC 9(04).
03 FILLER PIC X(01).
03 ZIPCODE-P2 PIC 9(03).
01 NUM-ZIPCODE PIC X(07).
01 NUM-ZIPCODE-R REDEFINES NUM-ZIPCODE.
03 ZIPCODE-P1 PIC 9(04).
03 ZIPCODE-P2 PIC 9(03).
MOVE CORR TX-ZIPCODE-R TO NUM-ZIPCODE-R.
IF NUM-ZIPCODE IS NOT NUMERIC
* ERRO
END-IF.
Hope I have help you! :)
I would like to ask, how to move number in Text, e.g: 01 A PIC X(6) value "200030", to a number such as 01 B PIC 9(6) and I only want to extract the first 4 number of A. In Cobol this type of move using MOVE is forbidden, the move I used is MOVE A(1:4) to B.
It is not forbidden
you just need to
03 Field-x4 X(4).
03 Field-94 9(4).
Move Field-X4 to Field-94
COBOL provides a few ways to accomplish this sort of assignment. Start with
the declarations outlined in your question:
01 A PIC X(6) VALUE "200030".
01 B PIC 9(6).
Declare another data item along the lines of:
01 AAAABB.
05 AAAA PIC 9(4).
05 BB PIC 9(2).
The AAAABB declares a record structure (compound data item) containing two elementary
data items: AAAA and BB, both of which are numeric. Now you can do either of the
following:
MOVE A(1:4) TO B ; DISPLAY B
MOVE A TO AAAABB ; DISPLAY AAAA
DISPLAY BB
The displayed output will be:
002000
2000
30
Since AAAABB is a compound item it has a PIC X implicit data type. This in turn
allows you to assign virtually any data value and then decompose it by referring
to its individual components.
Beware, an assignment such as:
MOVE A TO AAAA; DISPLAY AAAA
This will generally compile (with warnings about truncation) and produce the following
result:
0030
The most significant digits have been truncated (probably not what you wanted).
COBOL is reasonably flexible with respect to data manipulation. One
thing you should be watching out for (guarding against) is assginment of non-numeric
values to numeric data items as in:
MOVE "20++30" TO A
MOVE A TO AAAABB
This will "work" just fine until you try to do something like:
ADD +1 TO AAAA
If you are lucky it will blow up at this point (depending on your compiler and
the actual non-numerics). To guard against this type of error you should always
include logic along the lines of:
MOVE A TO AAAABB
IF (AAAA NOT NUMERIC) OR (BB NOT NUMERIC)
PERFORM BAD-DATA-ASSIGNMENT
END-IF
ADD 1 TO AAAA
You can do unions in COBOL with redefines. This is from memory but I think it should work:
01 YEARMONTH.
03 YM-FULL PIC 9(6).
03 FILLER REDEFINES YM-FULL.
05 YM-YEAR PIC 9(4).
05 YM-MONTH PIC 9(2).
01 JUST-YEAR PIC 9(4).
MOVE 200030 TO YM-FULL.
MOVE YM-YEAR TO JUST-YEAR.