Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Meaning of 'Move high values to var1'
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
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    Post subject: Meaning of 'Move high values to var1'
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: 2360
Location: Israel

PostPosted: Tue Jan 29, 2008 3:00 pm    Post subject:
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

Site Director


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

PostPosted: Tue Jan 29, 2008 10:42 pm    Post subject:
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    Post subject:
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: 2360
Location: Israel

PostPosted: Thu Jan 31, 2008 3:11 pm    Post subject:
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

Senior Member


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

PostPosted: Thu Jan 31, 2008 7:52 pm    Post subject:
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

Senior Member


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

PostPosted: Thu Jan 31, 2008 8:17 pm    Post subject:
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

Site Director


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

PostPosted: Thu Jan 31, 2008 9:01 pm    Post subject:
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    Post subject:
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

Senior Member


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

PostPosted: Thu Jan 31, 2008 10:40 pm    Post subject:
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

Site Director


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

PostPosted: Fri Feb 01, 2008 12:48 am    Post subject:
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    Post subject:
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    Post subject:
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

Site Director


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

PostPosted: Fri Feb 01, 2008 1:17 am    Post subject:
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    Post subject:
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    Post subject:
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

Site Director


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

PostPosted: Fri Feb 01, 2008 4:07 am    Post subject:
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

Site Director


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

PostPosted: Fri Feb 01, 2008 4:12 am    Post subject:
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    Post subject:
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    Post subject:
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
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts How to move a long alphanumeric data ... lind sh COBOL Programming 5 Mon Dec 05, 2016 7:51 pm
No new posts High CPU consumption Job using IAM fi... aswinir JCL & VSAM 8 Thu Dec 01, 2016 8:28 pm
No new posts Overlaying one set of charater values... Kevin Lindsley SYNCSORT 7 Sat Nov 05, 2016 3:21 am
No new posts Low values Results from VARCHAR FORMAT balaji81_k DB2 10 Thu Oct 20, 2016 1:18 am
No new posts Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us