IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Meaning of 'Move high values to var1'


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Ashsih

New User


Joined: 20 Dec 2007
Posts: 29
Location: India

PostPosted: Tue Jan 29, 2008 2:27 pm
Reply with quote

What is the meaning of following move stmnt.
Move high values to var1.
Mov low values to var2.
I thing purpose of one of the above stmn id for intilize like numeric with zero but lit confuse.
Back to top
View user's profile Send private message
ofer71

Global Moderator


Joined: 27 Dec 2005
Posts: 2358
Location: Israel

PostPosted: Tue Jan 29, 2008 3:00 pm
Reply with quote

You can read the fine manual in order to solve the confusion.

O.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Jan 29, 2008 10:42 pm
Reply with quote

Hello,

Quote:
I thing purpose of one of the above stmn id for intilize like numeric with zero but lit confuse.
No, it is not to initialize a numeric with zero.

If you look in the manual linked above and find someting that is not clear to you, post what you found and your question(s) and someone here will be able to clarify.
Back to top
View user's profile Send private message
KEVINSAU

New User


Joined: 16 Jan 2008
Posts: 2
Location: Wuhan,China

PostPosted: Thu Jan 31, 2008 1:12 pm
Reply with quote

I guess you are dealing with numeric data. In my team, when SA say "move low values to CNTNBR", we move zeros to that variable.
and high values, meaning 999..99. the number of '9' should be the same of the maximum length your variable may contains.
Back to top
View user's profile Send private message
ofer71

Global Moderator


Joined: 27 Dec 2005
Posts: 2358
Location: Israel

PostPosted: Thu Jan 31, 2008 3:11 pm
Reply with quote

KEVINSAU -

In the mainframe world, the high value is usually the hexadecimal value 'FF'.

O.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Thu Jan 31, 2008 7:52 pm
Reply with quote

Hi,

...And HIGH-VALUE represents X'FF'. These equate to the lower and upper limits of the collating sequence. All other values fall in between.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Thu Jan 31, 2008 8:17 pm
Reply with quote

oops..I wanted to say..
Quote:
And LOW-VALUE represents X'00'.
apologies..
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Jan 31, 2008 9:01 pm
Reply with quote

Hello,

Quote:
I guess you are dealing with numeric data. In my team, when SA say "move low values to CNTNBR", we move zeros to that variable.
and high values, meaning 999..99. the number of '9' should be the same of the maximum length your variable may contains.
It is good to make sure that what someone "says" is not confused with what happens in COBOL. On your team, low/high-values may mean zeros and nines, but this is not the way COBOL works.

On one of our systems, low and high-values cannot even be moved to a zoned-decimal (using the Enterprise COBOL compiler).

When low and high-values are used, the lowest and highest value in the collating sequence are referenced. On the mainframe (as well as all of the systems that use 8-bit ascii) these are x'00' and x'FF'.
Back to top
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Thu Jan 31, 2008 9:37 pm
Reply with quote

KEVINSAU wrote:
In my team, when SA say "move low values to CNTNBR", we move zeros to that variable.
and high values, meaning 999..99. the number of '9' should be the same of the maximum length your variable may contains.


I feel sorry for your team (and your customers).
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Thu Jan 31, 2008 10:40 pm
Reply with quote

dick scherrer wrote:
(as well as all of the systems that use 8-bit ascii)
ah..You usually give me complex with the knowledge you carry .. icon_mad.gif . How do you know this now?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Feb 01, 2008 12:48 am
Reply with quote

Hi Anuj,

Quote:
How do you know this now?
An easy way to verify this is to look at some file in hex on either a UNIX or Win-based system.

Something that sometimes helps clarify is to create a little file on the mainframe with 16 records - each record having 16 1-byte values with spaces in between (for readability). The first record would have the 16 values from x'00' to x'0F', the second the values from x'10' to x'1F' and so on until the last record that would have x'F0' to x"FF'.

FTP this file to an ascii system, look at it in hex, and notice the conversion that has taken place.
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 01, 2008 12:53 am
Reply with quote

When I transfer low-values to the PC these low-values go away causing all columns to the right to be shifted left. Low-values x'00' is null in ASCII.
Back to top
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Fri Feb 01, 2008 1:03 am
Reply with quote

Douglas Wilder wrote:
When I transfer low-values to the PC these low-values go away causing all columns to the right to be shifted left. Low-values x'00' is null in ASCII.


I have done just what DICK suggested and never had any trouble with the x'00' disappearing, must depend on what you use on the PC to look at the file.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Feb 01, 2008 1:17 am
Reply with quote

Hello,

Quote:
When I transfer low-values to the PC these low-values go away causing all columns to the right to be shifted left. Low-values x'00' is null in ASCII.
Depends. . . Did you create the file i mentioned?

I just did (with only the first record from x'00' to x'0F') and ftp'ed it both in ascii and in binary and in neither case did the x'00' have problems.
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 01, 2008 3:07 am
Reply with quote

Here only the production scheduling package can FTP any files to or from the MF. Since I can not FTP, I used TN3270 file transfer. I have had this problem on several files being opened with several different types of PC software both DOS and Windows, including a file of all 256 char x'00' to x'FF'. This must be a feature of TN3270, since you state that FTP both ASCII and binary do not have this problem. I had thought it was just the way PCs handled the NUL char. I learned another new thing today.
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 01, 2008 3:43 am
Reply with quote

I was wrong. I had been told so many time by our LAN Software developers that the x'00' were being dropped and that they had verified this with several different programs, that I did not this time test it myself. Now I tested it myself and I find that now they are not being dropped. I will have to go back to those same developers and find our what they were talking about. The solution we had always jumped to before was to convert those characters to something else before transferring the files. Now I find that was not the problem? This does not make me happy.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Feb 01, 2008 4:07 am
Reply with quote

Hello,

Quote:
Here only the production scheduling package can FTP any files to or from the MF.
This may be good for production file transfers. Might there be an ftp service running on the mainframe that pretty much allows the same file access as your TSO id? If so, you might be able to download "your" files to a win-based system by logging onto the mf/ftp service and downloading what you need.

With TN3270, is there a way to specify a "binary" or non-translated transfer (been too long since is was connectec via TN3270)?

Regardless of transfer method, what i've found over time is that unless there is some special need on the win/unix side, it is best to make sure the entire content of a file is "text".
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Feb 01, 2008 4:12 am
Reply with quote

Hello again (we're overlapping icon_smile.gif )

Quote:
The solution we had always jumped to before was to convert those characters to something else before transferring the files. Now I find that was not the problem? This does not make me happy.
No, i imagine it does not. . .

I'd still be tempted to remove the x'00's (and any other strange values) before dong the transfer - unless there was something useful to be served on the target system.
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 01, 2008 4:52 am
Reply with quote

There have been several projects over the past few years, where originally we were told, "Just transfer your main frame file to the LAN and they will convert it to the format they need." In each case, we were later told, "they could not convert our data because the low-values were being dropped and all fields after that were being shifted. " We ended up, for each project, converting the files to all display fields before the file transfer was done. After a while I just started building that into my estimates even if they told me it would not be needed.
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 01, 2008 4:54 am
Reply with quote

In our cases the low-values x'00' were usually the leading zeroes in packed or binary numbers.
Back to top
View user's profile Send private message
stodolas

Active Member


Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin

PostPosted: Fri Feb 01, 2008 5:39 am
Reply with quote

The LAN can't convert the packed fields unless they use a COBOL compiler that implements packed storage the in the same fashion that the mainframe compiler does. It basically needs display fields.
Back to top
View user's profile Send private message
KEVINSAU

New User


Joined: 16 Jan 2008
Posts: 2
Location: Wuhan,China

PostPosted: Fri Feb 01, 2008 9:05 am
Reply with quote

Craq Giegerich wrote:
KEVINSAU wrote:
In my team, when SA say "move low values to CNTNBR", we move zeros to that variable.
and high values, meaning 999..99. the number of '9' should be the same of the maximum length your variable may contains.


I feel sorry for your team (and your customers).


//Our team is excellent, except me. icon_razz.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts INCLUDE OMIT COND for Multiple values... DFSORT/ICETOOL 5
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts Null values are considered in Total c... DFSORT/ICETOOL 6
No new posts COBOL - Move S9(11)v9(7) COMP-3 to -(... COBOL Programming 5
No new posts ISRSUPC search utility - using high l... TSO/ISPF 2
Search our Forums:

Back to Top