MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

COBOL Picture Clause Editing S0C7

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Tue Apr 17, 2018 11:06 am    Post subject: COBOL Picture Clause Editing S0C7 Reply with quote

Hello,

I have below code. When I provide input as "123!A" it doesnt give S0C7 but when I provide input as "12!3A" it gives S0C7. I understand I am providing incorrect input but just curious to know why in one case it gives 0C7. I was expecting it to fail in both cases.
Code:

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-Z-VAR    PIC ZZZZ9.
LINKAGE SECTION.
01 LS-PARM.
   05 LS-PARM-LENGTH   PIC S9(4) COMP.
   05 LS-CHAR1         PIC X(05).
PROCEDURE DIVISION USING LS-PARM.
0000-MAIN.
    DISPLAY 'LS-CHAR1 : >' LS-CHAR1 '< '
    MOVE LS-CHAR1  TO WS-Z-VAR
    DISPLAY 'WS-Z-VAR : >' WS-Z-VAR '< '
    GOBACK.
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Tue Apr 17, 2018 12:34 pm    Post subject: Reply with quote

rsantosh,

You need to understand how the compiler generates the instructions. Since you are moving a zoned decimal value to a zero suppressed output, the COBOL compiler will generate a PACK and ED instructions.

12!3A = X'F1F25AF3C1' will be packed in to 3 Byte value which will be of this format
Code:

00 00 00
12 A3 1C


X'A3' is an invalid packed decimal number and hence the S0C7

Now you passed

123!A = X'F1F2F35AC1' will be packed in to 3 Byte value which will be of this format
Code:

00 00 00
12 3A 1C


And X'3A' is a valid packed decimal number and hence no abend.

If you passed 1!23A = X'F15AF2F3C1' will be packed in to 3 Byte value which will be of this format
Code:

00 00 00
1A 23 1C


Notice that all are valid packed decimal values and hence you will not get an abend.

If you want to see the listing that the COBOL compiler generates then add the following at the top of cobol program( before the identification division) and see the sysprint listing.
Code:

CBL LIST

_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Tue Apr 17, 2018 11:36 pm    Post subject: Reply with quote

Hello Kolusu,

Thank you. Is
Code:
 12 3A 1C
a valid packed decimal number?
You shook my basic understanding of the packed decimal. Smile

All these years I used to think only the rightmost nibble(signed nibble) of packed decimal can contain A-F. Other nibbles must have 0-9 to make it a valid packed number.

So if a packed decimal has
Code:
 12 3A 1C
and I do arithmatic operation on it I wont receive S0C7?(will test this when I go to work later)

Santosh
Back to top
View user's profile Send private message
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Tue Apr 17, 2018 11:42 pm    Post subject: Reply with quote

Hello Kolusu,

Or is it that EDIT tests for the validity of packed number byte wise? So on a whole 123A1C is an invalid packed decimal numebr but EDIT goes byte by byte and hence treats 3A (2nd byte) as a valid packed number?

Santosh
Back to top
View user's profile Send private message
Nic Clouston
Advanced


Joined: 01 Feb 2007
Posts: 1075
Topics: 7
Location: At Home

PostPosted: Wed Apr 18, 2018 6:06 am    Post subject: Reply with quote

what you have in this example is your original 'number' when packed is now two numbers:x'123A' and x'1C'. Both are valid but not as 1 number.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.
Back to top
View user's profile Send private message
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Wed Apr 18, 2018 6:36 am    Post subject: Reply with quote

Hi Nic,

Thank you. So how does EDIT treat this pakced value "123A1C", as one number "123A1C" or two numbers "123A" & "1C" or one byte at a time "12" "3A" "1C"?

I found the flow diagram of EDIT in page 573. It says "sign code in source byte". Just wondering if EDIT is actually checking one byte at a time and when it encounters 3 then "sign code in source byte?" is true and hence no S0C7.

http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf

Santosh
Back to top
View user's profile Send private message
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Wed Apr 18, 2018 6:45 am    Post subject: Reply with quote

EDIT --> Assembler instruction. I compiled the program with LIST option and checked the generated instruction.
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Wed Apr 18, 2018 11:20 am    Post subject: Reply with quote

rsantosh wrote:

You shook my basic understanding of the packed decimal. Smile

All these years I used to think only the rightmost nibble(signed nibble) of packed decimal can contain A-F. Other nibbles must have 0-9 to make it a valid packed number.


rsantosh,

Your understanding is still correct, what I described is how the PACK instruction in assembler works.

To convert from zoned to packed
Code:

Format: label    PACK  D1(L1,B1),D2(L2,B2)


PACK Instruction wrote:

- Packs the L2 byte zoned decimal number at D2(B2)
and stores it as a L1 byte packed decimal number at D1(B1)

- The packing process:

1. The zone and numeric digit of the rightmost byte of
the zoned decimal number are reversed and placed in the
rightmost byte of the packed decimal number


2. The remaining numeric digits are moved to the packed decimal
number, proceeding from right to left. If the zoned
number has more digits than the packed number can hold, the
extras are ignored. If the zoned number has less digits
than the packed number, the remaining packed digits are
filled with zero

- The second operand does NOT have to be a valid zoned decimal
number


Suppose FLD1 is 4 packed bytes and FLD2 is 7 zoned bytes, with the
initial values:
Code:

  FLD1     00 00 00 00
  FLD2     F9 F8 F7 F6 F5 F4 F3

Execution of:
Code:

  PACK  FLD1(4),FLD2(7)         will set FLD1 to    98 76 54 3F

  PACK  FLD1(3),FLD2(7)         will set FLD1 to    76 54 3F 00

  PACK  FLD1(4),FLD2(5)         will set FLD1 to    00 98 76 5F


rsantosh wrote:

and I do arithmatic operation on it I wont receive S0C7?(will test this when I go to work later)


Depends on how you are doing the arithmetic. You cannot perform arithmetic on numeric edited or character data. So you either need to redefine and do the arithmetic. So lets for a min assume that you did indeed redefined the value as zoned decimal, then now it comes down to how you are performing the arithmetic, whether you are doing arithmetic on each individual bytes or as a whole. It also depends on the compiler option NUMPROC whether the signs need to be considered.

rsanthosh wrote:
Or is it that EDIT tests for the validity of packed number byte wise? So on a whole 123A1C is an invalid packed decimal numebr but EDIT goes byte by byte and hence treats 3A (2nd byte) as a valid packed number?


for the EDit instruction, the pattern and packed decimal number are both processed from left to right. The pattern is processed one BYTE at a time, while the packed decimal number is processed one DIGIT at a time.

A data exception (SOC 7) will occur if the second operand is not a valid packed decimal number.
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
rsantosh
Beginner


Joined: 20 Dec 2014
Posts: 38
Topics: 9

PostPosted: Wed Apr 18, 2018 9:42 pm    Post subject: Reply with quote

Hello Kolusu,

Thank you for the detailed explanation. It is very useful.

Santosh
Back to top
View user's profile Send private message
t-bonham@scc.net
Supermod


Joined: 18 Oct 2012
Posts: 30
Topics: 0
Location: Minneapolis, MN

PostPosted: Thu Apr 19, 2018 8:28 pm    Post subject: Reply with quote

rsantosh wrote:
Thank you for the detailed explanation. It is very useful.
Santosh
Even more useful in a system, is tight editing of input data, so you don't end up with crap like this in a packed numeric field!
Back to top
View user's profile Send private message Send e-mail AIM Address
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group