COMP-3 and Alpha numeric

Hi
I have one question on COMP-3 variables.
I use Z/OS with VS COBOL II.

The problem i'm facing:
I have two variables declared as
05 WS-VAR1    PIC S(9)V99.
05 WS-VAR2    PIC X(11).

The program i'm analyzing has the following move statement:
MOVE WS-VAR1                     TO   WS-VAR2

The issue that i'm analyzing is that WS-VAR2 is moved to a file and it
appears similar to LOW-VALUES (when file is opened in browse mode).

To test if the move is legal, i wrote a simple display program with the
above move statement and displayed WS-VAR2. (WS-VAR1 had 123456789 as
data)

The program compiles fine (returns a 0 RC). However, when i run this
program, the VAR2 displays junk.

Am i doing this right? What am I missing?

>From my understanding, COBOL II should be allowing automatic type
conversions and the move statement should not be an issue.

Regards,
Aanand

fatalxception wrote:
> Hi
> I have one question on COMP-3 variables.
> I use Z/OS with VS COBOL II.
>
> The problem i'm facing:
> I have two variables declared as
> 05 WS-VAR1    PIC S(9)V99.
> 05 WS-VAR2    PIC X(11).

Neither of which are COMP-3 variables.

Preface:
VS COBOL II hasn't been supported for years.
As someone else pointed out, neither of these are "COMP-3"

OK, for an answer:
If you look at the chart at:

http://publibz.boulder.ibm.com/cgi-...S/IGYR1101/3.22

It explicitly states that a move from a NON-INTEGER numeric sending item to 
an
ALPHANUMERIC receiving item is NOT valid (supported).  If you aren't getting
 a
compiler error, then I would question if you have compiled with "FLAG(I,I) t
o
actually SEE all your compiler errors.

Try compiling again with FLAG(I,I) and show us the listing lines "around" yo
ur
move (and your actual data definitions) and we might be able to give you a
better answer.

NOTE: adding COMP-3 to the numeric data item should NOT change the fact that
this should get a compiler error.

--
Bill Klein
wmklein <at> ix.netcom.com
"fatalxception" <aanand.ramesh@gmail.com> wrote in message
news:1158306607.043544.326680@e3g2000cwe.googlegroups.com...
> Hi
> I have one question on COMP-3 variables.
> I use Z/OS with VS COBOL II.
>
> The problem i'm facing:
> I have two variables declared as
> 05 WS-VAR1    PIC S(9)V99.
> 05 WS-VAR2    PIC X(11).
>
> The program i'm analyzing has the following move statement:
> MOVE WS-VAR1                     TO   WS-VAR2
>
> The issue that i'm analyzing is that WS-VAR2 is moved to a file and it
> appears similar to LOW-VALUES (when file is opened in browse mode).
>
> To test if the move is legal, i wrote a simple display program with the
> above move statement and displayed WS-VAR2. (WS-VAR1 had 123456789 as
> data)
>
> The program compiles fine (returns a 0 RC). However, when i run this
> program, the VAR2 displays junk.
>
> Am i doing this right? What am I missing?
> 
> conversions and the move statement should not be an issue.
>
> Regards,
> Aanand
>

> "fatalxception" <aanand.ramesh@gmail.com> wrote in message
> news:1158306607.043544.326680@e3g2000cwe.googlegroups.com... 

Well then let me complete your analysis:

The program is doing something either illegal, immoral or fattening, because
given these PICTURE clauses, that MOVE statement is totally silly (i.e.,
meaningless and purposeless).

MOVEing the other way....

MOVE WS-VAR2 TO WS-VAR1 could make sense, but only  only after you had
done ...
IF WS-VAR2 IS NUMERIC....

OR....

Did you perhaps not post the "REDEFINES WS-VAR1" which appears after
WS-VAR2? (I doubt it because of the full stop following the PIC X(11) but
it's not like we've never seen mis-posts before).

MCM

fatalxception wrote:

> I have one question on COMP-3 variables.
> I use Z/OS with VS COBOL II.
>
> The problem i'm facing:
> I have two variables declared as
> 05 WS-VAR1    PIC S(9)V99.
> 05 WS-VAR2    PIC X(11).

I will assume that you actually meant that WS-VAR1 is COMP-3.

> The program i'm analyzing has the following move statement:
> MOVE WS-VAR1                     TO   WS-VAR2

This is an invalid move as already pointed out, it gives a compiler
error with my compilers and does not generate a program that would run.
It is possible your compiler may allow it, but unlikely, so I doubt
that the code you wrote as an illustration is an actual representation
of what the program does.

> The issue that i'm analyzing is that WS-VAR2 is moved to a file and it
> appears similar to LOW-VALUES (when file is opened in browse mode).

If Var1 had a value of zero then it would be 5 bytes of hex '00' and
one byte of hex '0F' or similar.  This is identical to low values for
the first 5 bytes.  In fact any value less than 10000000.00 would have
low-values in the first byte.

> To test if the move is legal, i wrote a simple display program with the
> above move statement and displayed WS-VAR2. (WS-VAR1 had 123456789 as
> data)

> The program compiles fine (returns a 0 RC). However, when i run this
> program, the VAR2 displays junk.

Are you sure that the program does an actual MOVE as you claim ?
Perhaps it has:

03  Var1-Group COMP-3.
05 Var1      PIC S9(9)V99.
03  Var2     PIC X(11).

and then the compiler will happily allow MOVE Var1-Group TO Var2
resulting in junk in Var2.

> Am i doing this right? What am I missing?

Well you missed putting the COMP-3 on the code snippet above, perhaps
you missed telling us other things as well.
 
> conversions and the move statement should not be an issue.

COBOL is most likely doing exactly what COBOL does. It is probably your
understanding, not COBOL, that is flawed.

Post the _actual_ code and we can tell you in more detail what is
actually happening.

ooopss...
my mistake on the declaration.
as Richard assumed.. WS-VAR1 is COMP-3.

Update on this:

I wrote a program which just moved VAR1 to VAR2 and displayed VAR2.
wonder of wonders, it worked!!!

I'm not sure how or what happened, but that program worked.

The program had no other logic other than this. WS-VAR1 had an initial
value of 1234567 while WS-VAR2 was initialized using INITIALIZE verb.

The program displayed WS-VAR2 perfectly as 1234567(with spaces of
course).

Also, the code is as i've put in (with the major addition of the COMP-3
clause) and as u've already pointed out, maybe my understanding may not
be upto the mark.

(I have not put in the exact variable names as i do not think it should
be an issue.)

so folks, how do i explain the above?
I even tested the program that I'm analyzing and i found the report
(the program generates) had no issues displaying the variable in
question.

Regards,
Aanand


Richard wrote:
> fatalxception wrote:
> 
>
> I will assume that you actually meant that WS-VAR1 is COMP-3.
> 
>
> This is an invalid move as already pointed out, it gives a compiler
> error with my compilers and does not generate a program that would run.
> It is possible your compiler may allow it, but unlikely, so I doubt
> that the code you wrote as an illustration is an actual representation
> of what the program does.
> 
>
> If Var1 had a value of zero then it would be 5 bytes of hex '00' and
> one byte of hex '0F' or similar.  This is identical to low values for
> the first 5 bytes.  In fact any value less than 10000000.00 would have
> low-values in the first byte.
> 
> 
>
> Are you sure that the program does an actual MOVE as you claim ?
> Perhaps it has:
>
>         03  Var1-Group COMP-3.
>          05 Var1      PIC S9(9)V99.
>         03  Var2     PIC X(11).
>
> and then the compiler will happily allow MOVE Var1-Group TO Var2
> resulting in junk in Var2.
> 
>
> Well you missed putting the COMP-3 on the code snippet above, perhaps
> you missed telling us other things as well.
> 
>
> COBOL is most likely doing exactly what COBOL does. It is probably your
> understanding, not COBOL, that is flawed.
>
> Post the _actual_ code and we can tell you in more detail what is
> actually happening.

Please show your EXACT source code and listing.  As I stated before, IBM sim
ply
does NOT support moving a non-integer numeric (any USAGE) to an alphanumeric
receiving field.  I really, REALLY, think you are doing something different 
in
the actual source code than what you are reporting.

--
Bill Klein
wmklein <at> ix.netcom.com
"fatalxception" <aanand.ramesh@gmail.com> wrote in message
news:1158548688.620445.321240@d34g2000cwd.googlegroups.com...
> ooopss...
> my mistake on the declaration.
> as Richard assumed.. WS-VAR1 is COMP-3.
>
> Update on this:
>
> I wrote a program which just moved VAR1 to VAR2 and displayed VAR2.
> wonder of wonders, it worked!!!
>
> I'm not sure how or what happened, but that program worked.
>
> The program had no other logic other than this. WS-VAR1 had an initial
> value of 1234567 while WS-VAR2 was initialized using INITIALIZE verb.
>
> The program displayed WS-VAR2 perfectly as 1234567(with spaces of
> course).
>
> Also, the code is as i've put in (with the major addition of the COMP-3
> clause) and as u've already pointed out, maybe my understanding may not
> be upto the mark.
>
> (I have not put in the exact variable names as i do not think it should
> be an issue.)
>
> so folks, how do i explain the above?
> I even tested the program that I'm analyzing and i found the report
> (the program generates) had no issues displaying the variable in
> question.
>
> Regards,
> Aanand
>
>
> Richard wrote: 
>

fatalxception wrote:
> ooopss...
> my mistake on the declaration.
> as Richard assumed.. WS-VAR1 is COMP-3.
>
> Update on this:
>
> I wrote a program which just moved VAR1 to VAR2 and displayed VAR2.
> wonder of wonders, it worked!!!
>
> I'm not sure how or what happened, but that program worked.
>
> The program had no other logic other than this. WS-VAR1 had an initial
> value of 1234567 while WS-VAR2 was initialized using INITIALIZE verb.
>
> The program displayed WS-VAR2 perfectly as 1234567(with spaces of
> course).
>
> Also, the code is as i've put in (with the major addition of the COMP-3
> clause) and as u've already pointed out, maybe my understanding may not
> be upto the mark.
>
> (I have not put in the exact variable names as i do not think it should
> be an issue.)
>
> so folks, how do i explain the above?
> I even tested the program that I'm analyzing and i found the report
> (the program generates) had no issues displaying the variable in
> question.

Post the code and we will tell you - the one that you say has no logic
other than the MOVE.

Also you need to explain what 'it worked!!!' means.  I know what my
expectations are for the code* that you describe, but I have no idea
what your expectations were or what happened to make you say that it
met these.


(* my expectations are a compiler error).

fatalxception wrote:

> ooopss...
> my mistake on the declaration.
> as Richard assumed.. WS-VAR1 is COMP-3.
>
> Update on this:
>
> I wrote a program which just moved VAR1 to VAR2 and displayed VAR2.
> wonder of wonders, it worked!!!
>
> I'm not sure how or what happened, but that program worked.

Your original was:
 
 

This should give an error "NON-INTEGER to alphanumeric".

Note that 'NON-INTEGER' means that it has a decimal part - V99.

> The program had no other logic other than this. WS-VAR1 had an initial
> value of 1234567 while WS-VAR2 was initialized using INITIALIZE verb.

> The program displayed WS-VAR2 perfectly as 1234567(with spaces of
> course).

If Var1 was actually PIC S9(7) COMP-3, and had no 'V' as in your
original, then moving it to a alphanumeric PIC X(nn) is perfectly valid
and a value of 1234567 (note no decimal point - an integer) will unpack
it and will display the digits.

> Also, the code is as i've put in (with the major addition of the COMP-3
> clause) and as u've already pointed out, maybe my understanding may not
> be upto the mark.
>
> (I have not put in the exact variable names as i do not think it should
> be an issue.)
>
> so folks, how do i explain the above?
> I even tested the program that I'm analyzing and i found the report
> (the program generates) had no issues displaying the variable in
> question.

The explanation is, most likely, that you haven't told the actual
situation.

fatalxception wrote:
> ooopss...
> my mistake on the declaration.
> as Richard assumed.. WS-VAR1 is COMP-3.
>
> Update on this:
>
> I wrote a program which just moved VAR1 to VAR2 and displayed VAR2.
> wonder of wonders, it worked!!!
>
> I'm not sure how or what happened, but that program worked.
>
> The program had no other logic other than this. WS-VAR1 had an initial
> value of 1234567 while WS-VAR2 was initialized using INITIALIZE verb.
>
> The program displayed WS-VAR2 perfectly as 1234567(with spaces of
> course).
>
> Also, the code is as i've put in (with the major addition of the
> COMP-3 clause) and as u've already pointed out, maybe my
> understanding may not be upto the mark.
>
> (I have not put in the exact variable names as i do not think it
> should be an issue.)
>
> so folks, how do i explain the above?
> I even tested the program that I'm analyzing and i found the report
> (the program generates) had no issues displaying the variable in
> question.
>
> Regards,
> Aanand

Two years ago, a couple of interesting things happened. An idiot legislator
in Michigan proposed an "open hunting season on feral cats" and, about the
same time, I ran into R. Lee Ermy ("Mail Call" on the History Channel) at an
NRA convention. I reminded him about the proposed cat-culling legislation,
then asked:

"Lee, I'm putting together a tape of celebrity 'cat-calls'. Would you be
interested in saying 'Here, kitty-kitty' for the project?"

He looked up from the autographs he was signing and said: "That is the most
XXXXed-up idea I EVER heard!"

I don't know what it is about your endeavor that brought this episode to
mind.....