i have input record with
part - pic x(10),
country - pic x(03),
department - pic x(07),
year - pic x(04),
count1 - PIC S9(9) COMP-3,
count2 - PIC S9(9) COMP-3,
count3 - PIC S9(9) COMP-3,
count4 - PIC S9(9) COMP-3,
count5 - PIC S9(9) COMP-3,
USAGE - PIC S9(5)V9(4) COMP-3,
in output record i have to sum up all the counts and then divide it by usage,
if the value after divide is in decimal then need to round of to near value.
after round off then add all the counts for each record at part & model year level.
means for all the departments if part & year are same i need to make them into one record by summing up count.
please suggest me any solution.
i need to do this in JCL using sort keys only.
Related
My problem is: I have data in a database table. The column is: Z-ZYTL-RTPDHR defined as NOT NULL NUMBER(5,2) .
So I have a program that I need to move my data in one variable "H-ZYTL-RTPDHR" and after I will move this value divide by 100 in one column Z8 when i compile i obtained Excel with data in the different column.
My data:
Z8
------
34,28
70
97
8,57
21,43
94,28
94,28
100
40
40
what I should get:
Z8
-------
0,3428
0,7
0,97
0,0857
0,2143
0,9428
0,9428
0,100
0,40
0,40
my question how to declare the variable to obtain the good result?
Variables that I declared:
01 FILLER.
05 H-ZYTL-RTPDHR.
10 PIC S9(5)V9(2) comp-3 VALUE.
05 FILLER REDEFINES H-ZYTL-RTPDHR.
10 H-ZYTL-RTPDHR comp-3 pic s9(5)v99.
Equivalent Temps Plein
05 W-Z8 PIC -(5),99.
05 FILLER PIC X(001) VALUE ';'.
ALIM-WZ8 SECTION.
IF Z-ZYTL-NOMBRE > ZERO
IF TLCODTRA(Z-ZYTL-NOMBRE) NOT = SPACES
MOVE Z-ZYTL-RTPDHR(Z-ZYTL-NOMBRE) TO
H-ZYTL-RTPDHR
DISPLAY 'H-ZYTL-RTPDHR:' H-ZYTL-RTPDHR
DIVIDE H-ZYTL-RTPDHR BY 100 GIVING W-Z8
DISPLAY 'W-Z8 : ' W-Z8
END-IF
END-IF.
You have defined the name H-ZYTL-RTPDHR twice: that will confuse you and and the compiler as well.
Your second definition of H-ZYTL-RTPDHR is good for doing arithmetic. All you need is
01 FILLER.
10 H-ZYTL-RTPDHR comp-3 pic s9(5)v99.
Your first definition of H-ZYTL-RTPDHR defines a group level item, and you can't do arithmetic with it.
However, your question doesn't show the definition of Z-ZYTL-RTPDHR. If it's not numeric, then you won't get the results you expect.
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.
I have a field pic X(03) with a date in it as X'160101' format yymmdd.
I will like to know how to convert it to pic x(06).
So far I tried to move it back to a 9(03) comp and move the
9(03) comp to a 9(06) but it didn't work.
How can I do this?
What you have is a Binary Coded Decimal (BCD). That is, the data is held in a binary field, but it is the decimal representation, not the binary, which is important for the value. X'160101' in would be 1,442,049. X'160201' would be 1,442,305. So if you were able to treat it as a binary field (you'd have to prepend a binary zero to make it the correct length for a binary field) you'd have to do some silly calculation.
So you do something different, and easier. BCD is not a native COBOL datatype. PACKED-DECIMAL (often the same as COMP-3/COMPUTATIONAL-3) is a BCD-type which includes a sign-value in the low-order (right-most) half-byte. So not quite a BCD, but you can treat your BCD as PACKED-DECIMAL like this:
01 BCD-TO-PACKED.
05 BTP-SOURCE-BCD PIC XXX.
05 BTP-PACKED-ZERO PACKED-DECIMAL PIC 9 VALUE ZERO.
01 FILLER
REDEFINES BCD-TO-PACKED.
05 BTP-PACKED-TO-MOVE
PAKCED-DECIMAL PIC 9(6)V9.
01 DATE-AS-PIC-X PIC X(6).
01 DATA-AS-CHARACTER-NUMERIC
REDEFINES DATE-AS-PIC-X PIC 9(6).
MOVE your-source-value TO BTP-SOURCE-BCD
MOVE BTP-PACKED-TO-MOVE TO DATA-AS-CHARACTER-NUMERIC
After that you can happily reference DATE-AS-PIC-X to do whatever you want with it.
BCD-TO-PACKED is a four-byte group field which, through the VALUE clause and through nothing ever changing, has, in the last by X'0F'. That's an unsigned packed-decimal field with one digit and a value of zero.
Then you do the X-to-X MOVE for BTP-SOURCE-BCD. BCD-TO-PACKED now looks like this: X'1601010F'. Which is perfectly valid for a packed-decimal field. You could divide that by 10 to get your date (REDEFINES it as PACKED-DECIMAL PIC 9(7)) but why waste CPU?
Instead, in the REDEFINES you define one decimal place (V9). When the compiler generates the code to MOVE that to another numeric field with no decimal places, the source decimal place(s) are just dropped off. Presto! Divide by 10 without dividing.
Note: The data-names chosen are to aid the explanation. You should make yours meaningful to the data, not just use "trite" names. "Character numeric" is called USAGE DISPLAY in COBOL, it is the default if a USAGE is not supplied. The word USAGE is rarely used itself. So USAGE DISPLAY is what you have when there is a PIC X or PIC 9 field with no other usage.
Note: You should probably not be using two-digit years. You won't be able to deal with dates earlier than 2000 or later than 2199. Historical use of two-digit years was due to expensive disk storage and "data redundancy" (all century values were 19, so why hold the value 19 80 different times for the same account). If using two-digit years, ensure that there is something somewhere which is relevant to the century.
Note: If you attempt to MOVE a PIC X field to a numeric field, the compiler will assume that you have valid character numbers in the field, which is one reason your original attempt failed.
If you search stackoverflow, you should find the answer (this has already been answered).
But Create a fields like (my-date-x holds the date):
03 my-date-x pic x(3).
03 my-date-9 pic 9(6).
03 date-ymdv0 pic 9(6)v9 comp-3.
03 date-x pic x(3) redefines date-ymdv0.
And the code is
Move 0 to date-ymdv0
Move my-date-x to date-x
Move date-ymdv0 to my-date-9
The reason it works is for 9(6)v9 comp3 160101 is stored as x'1601010c'
which is what you have (+ a 0c at the end).
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 having the following problem in a COBOL program running on OpenVMS.
I have the following variable declaration:
01 STRUCT-1.
02 FIELD-A PIC S9(6) COMP-3.
02 FIELD-B PIC S9(8) COMP-3.
01 STRUCT-2.
03 SUB-STRUCT-1.
05 FIELD-A PIC 9(2).
05 FIELD-B PIC 9(4).
03 SUB-STRUCT-2.
05 FIELD-A PIC 9(4).
05 FIELD-B PIC 9(2).
05 FIELD-C PIC 9(2).
And the following code:
* 1st Test:
MOVE 112011 TO FIELD-A OF STRUCT-1
MOVE 20100113 TO FIELD-B OF STRUCT-1
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1 CONVERSION
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1 CONVERSION
* 2nd Test:
MOVE 112011 TO SUB-STRUCT-1.
MOVE 20100113 TO SUB-STRUCT-2.
MOVE SUB-STRUCT-1 TO FIELD-A OF STRUCT-1
MOVE SUB-STRUCT-2 TO FIELD-B OF STRUCT-1
DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1
DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1 CONVERSION
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1 CONVERSION
Which outputs:
FIELD-A : 112011
FIELD-B : 20100113
SUB-STRUCT-1 : 112011
SUB-STRUCT-2 : 20100113
FIELD-A : 131323
FIELD-B : 23031303
Why FIELD-A and FIELD-B hold values different from what I move into them in the second test?
I've other moves from DISPLAY to COMP-3 variables in my program where I don't get this behavior.
In COBOL, Group level data are typeless and are moved without casting.
Element level data always have an associated data type. Typed
data are cast to match the type
of the receiving element during a MOVE.
In the first instance you MOVE a literal numeric value (112011) to a packed decimal field and the compiler converts it to the correct data type in the process. Just as you would expect in any programming language.
In the second instance you MOVE a literal value to a group item. Since this is a group item the compiler cannot 'know' the intended data type so it always does group moves as character data (no numeric conversions). This is fine when the receiving item has a PICTURE clause that is compatible with character data - which FIELD-A and FIELD-B
of SUB-STRUCT-1 are. There is no difference in the internal representation of a 9 when stored as PIC X and when stored as PIC 9. Both are assumed USAGE DISPLAY.
Now when you do a group level move from SUB-STRUCT-1 to a COMP-3 (Packed Decimal) you effectively tell the compiler not to convert from DISPLAY to COMP-3 format. And that is what you get.
Try the following modifications to your code. Using REDEFINES creates
a numeric elementary item for the move. COBOL will do the appropriate
data conversions when moving elementary data.
01 STRUCT-2.
03 SUB-STRUCT-1.
05 FIELD-A PIC 9(2).
05 FIELD-B PIC 9(4).
03 SUB-STRUCT-1N REDEFINES
SUB-STRUCT-1 PIC 9(6).
03 SUB-STRUCT-2.
05 FIELD-A PIC 9(4).
05 FIELD-B PIC 9(2).
05 FIELD-C PIC 9(2).
03 SUB-STRUCT-2N REDEFINES
SUB-STRUCT-2 PIC 9(8).
And the following code:
* 3RD TEST:
MOVE 112011 TO SUB-STRUCT-1.
MOVE 20100113 TO SUB-STRUCT-2.
MOVE SUB-STRUCT-1N TO FIELD-A OF STRUCT-1
MOVE SUB-STRUCT-2N TO FIELD-B OF STRUCT-1
DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1
DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1
Beware: Moving character data into a COMP-3 field may give you the dreaded SOC7 data exception abend when the receiving item is referenced. This is because not all bit patterns are valid COMP-3 numbers.
You have 2 Issues.
COBOL has several Numeric Data Structures. Each has its own set of rules.
For PACKED DECIMAL ( COMP-3 )
• The numeric components of the PIC clause should ALWAYS add up to an ODD number.
• The decimal marker “V” determines the placement of the decimal point.
• The individual element MOVE and math functions will maintain the decimal value alignment – both high and low level truncation is possible
• Numeric data type conversion (zone decimal to packed & binary to packed) is handled for you.
e.g. S9(5)V9(2) COMP-3.
including the 2 decimal positions>
Length is calculated as ROUND UP[ (7 + 1) / 2] = 4 bytes
S9(6)V9(2) COMP-3.
including the 2 decimal positions >
Length is calculated as ROUND UP[(8 + 1) / 2] = 5 bytes
But the 1st ½ byte is un-addressable
The last ½ byte of the COMP-3 fields is the HEXIDECIMAL representation of the sign.
The sign ½ byte values are C = signed positive D = signed negative F = unsigned (non COBOL).
S9(6)V9(3) COMP-3 VALUE 123.45.
Length is calculated as ROUND UP[(9 + 1) / 2] = 5 bytes
Contains X’00 01 23 45 0C’
Note the decimal alignment & zero padding.
Group Level MOVE rules
COBOL Data field structures are define as hierarchical structures.
The 01 H-L group field – & any sub-group level field –
Is almost always an implied CHARACTER string value
If an individual element field is a 01 or 77 level – then it can be numeric.
Individual element fields defined as a numeric under a group or sub-group level will be treated as numeric if referenced as an Individual element field.
Numeric rules apply.
o Right justify
o decimal place alignment
o pad H-L (½ bytes) with zeros
o Numeric data type conversion
The receiving field of a MOVE or math calculation determines if a numeric data conversion will occur.
Numeric Data Conversion
If you MOVE or perform a math calculation using any sending field type (group or element) to any receiving individual element field defined using a numeric PIC clause --- then numeric data conversion will occur for the receiving field. S0C7 abends occur when non-numeric data is MOVE ‘d to a receiving numerically defined field OR when math calculations are attempted using non-numeric data.
No Numeric Data Conversion
If you move any field type (group or element) to any group or sub-group level field then there will be NO numeric data conversion.
• Character MOVE rules apply.
• Left Justify & pad with spaces.
This is one of the primary causes of non-numeric data in a numerically defined field.
One of the primary uses of a sending group level MOVE containing numeric element fields to a receiving group level containing numeric element fields (mapped identically) is for re-initializing numeric element fields using 1 MOVE instruction.
A Clear Mask – or – a data propagation MOVE is also possible for table clears - where the table group level is greater than 255 bytes.