× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



So, it is like if we define as character. Because program A will receive the
data justify left, even we define as numeric.

Thank's a lots for your help.

Agus R

-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx]On Behalf Of Jon Paris
Sent: Monday, May 05, 2008 10:21 PM
To: COBOL Programming on the iSeries/AS400
Subject: Re: [COBOL400-L] Unmatch variable


Yes it is because the data definitions do not match. And you were
luck you were going long definition to short or you might not have
spotted it so easily.

This is nothing to do with AS/400 - and for that matter nothing to do
with COBOL really. It would happen with any version of COBOL and most
any language. The value that you see might be different on another
platform - but likely not.

When a parameter is passed by reference (the default on i5/OS
programs) only the address of the left-most byte is passed to the
called routine and its interpretation of the data is what counts.
Since the V is an implied decimal point (i.e. not really there) there
is no alignment around the decimal place. So when you pass in a 15
digit field and then treat it as 13 digits - the last two digits
"disappear" and the effect is as if you divided the value by 100.

You should _always_ make sure that the definitions of passed
parameters match - or you will be doomed ot a life of debugging nasty
problems.

Suppose for example you had done it the other way round and passed 13
digits and treated it as 15. When you set a value in the field you
would be changing 15 bytes of storage - but you only had 13 - so 2
bytes of (potentially) another variable's storage just got corrupted.



Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

On 5-May-08, at 6:01 AM, Riyadi, Agus wrote:

Hi All,

I don't now how AS/400 work, anybody can share with me ?

I have a program let say program A and this program will call sub
program B,

01 LK-OPT PIC X VALUE '1'.
01 LK-NBR PIC S9(11)V9(4) VALUE ZERO.
....

CALL PGM "B" USING LK-OPT LK-NBR.


But in program B

LINKAGE SECTION.
01 WK-OPT PIC X VALUE '1'.
01 WK-NBR PIC S9(9)V9(4) VALUE ZERO.
..
..
MOVE 1 TO WK-NBR.



My question is why LK-NBR become 100 ? Shoud be 1. Is this error
due to
different variable definition in A and B ?

rgds
Agus R


IMPORTANT NOTICE:
The information in this email (and any attachments) is
confidential. If you are not the intended recipient, you must not
use or disseminate the information. If you have received this email
in error, please immediately notify me by "Reply" command and
permanently delete the original and any copies or printouts
thereof. Although this email and any attachments are believed to
be free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and
no responsibility is accepted by American International Group, Inc.
or its subsidiaries or affiliates either jointly or severally, for
any loss or damage arising in any way from its use.
--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L)
mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.