Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes

 Meaning of 'Move high values to var1' Goto page 1, 2  Next
Author Message
Ashsih

New User

Joined: 20 Dec 2007
Posts: 29
Location: India

 Posted: Tue Jan 29, 2008 2:27 pm    Post subject: Meaning of 'Move high values to var1' 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.

ofer71

Global Moderator

Joined: 27 Dec 2005
Posts: 2360
Location: Israel

 Posted: Tue Jan 29, 2008 3:00 pm    Post subject: You can read the fine manual in order to solve the confusion. O.
dick scherrer

Site Director

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

Posted: Tue Jan 29, 2008 10:42 pm    Post subject:

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.
KEVINSAU

New User

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

 Posted: Thu Jan 31, 2008 1:12 pm    Post subject: 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.
ofer71

Global Moderator

Joined: 27 Dec 2005
Posts: 2360
Location: Israel

 Posted: Thu Jan 31, 2008 3:11 pm    Post subject: KEVINSAU - In the mainframe world, the high value is usually the hexadecimal value 'FF'. O.
Anuj Dhawan

Senior Member

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

 Posted: Thu Jan 31, 2008 7:52 pm    Post subject: 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.
Anuj Dhawan

Senior Member

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

Posted: Thu Jan 31, 2008 8:17 pm    Post subject:

oops..I wanted to say..
 Quote: And LOW-VALUE represents X'00'.
apologies..
dick scherrer

Site Director

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

Posted: Thu Jan 31, 2008 9:01 pm    Post subject:

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'.
Craq Giegerich

Senior Member

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

Posted: Thu Jan 31, 2008 9:37 pm    Post subject:

 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.

Anuj Dhawan

Senior Member

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

Posted: Thu Jan 31, 2008 10:40 pm    Post subject:

 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 .. . How do you know this now?
dick scherrer

Site Director

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

Posted: Fri Feb 01, 2008 12:48 am    Post subject:

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.
Douglas Wilder

Active User

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

 Posted: Fri Feb 01, 2008 12:53 am    Post subject: 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.
Craq Giegerich

Senior Member

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

Posted: Fri Feb 01, 2008 1:03 am    Post subject:

 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.
dick scherrer

Site Director

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

Posted: Fri Feb 01, 2008 1:17 am    Post subject:

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.
Douglas Wilder

Active User

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

 Posted: Fri Feb 01, 2008 3:07 am    Post subject: 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.
Douglas Wilder

Active User

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

 Posted: Fri Feb 01, 2008 3:43 am    Post subject: 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.
dick scherrer

Site Director

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

Posted: Fri Feb 01, 2008 4:07 am    Post subject:

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".
dick scherrer

Site Director

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

Posted: Fri Feb 01, 2008 4:12 am    Post subject:

Hello again (we're overlapping )

 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.
Douglas Wilder

Active User

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

 Posted: Fri Feb 01, 2008 4:52 am    Post subject: 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.
Douglas Wilder

Active User

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

 Posted: Fri Feb 01, 2008 4:54 am    Post subject: In our cases the low-values x'00' were usually the leading zeroes in packed or binary numbers.
 All times are GMT + 6 HoursGoto page 1, 2  Next
 Page 1 of 2

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics Low values Results from VARCHAR FORMAT balaji81_k DB2 10 Thu Oct 20, 2016 1:18 am Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm How can we create a flat file in JAVA... rakesh.v18 Java & MQSeries 7 Fri Sep 23, 2016 10:46 pm COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am Using 'parm' to vary SORTOUT record v... Sysaron DFSORT/ICETOOL 13 Wed Sep 07, 2016 9:24 pm

 © 2003-2016 IBM MAINFRAME Software Support Division
 Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us