|
View previous topic :: View next topic
|
| Author |
Message |
Ashsih
New User
Joined: 20 Dec 2007
Posts: 29
Location: India
|
|
|
|
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 |
|
 |
ofer71
Global Moderator
Joined: 27 Dec 2005
Posts: 2358
Location: Israel
|
|
|
|
You can read the fine manual in order to solve the confusion.
O. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
KEVINSAU
New User
Joined: 16 Jan 2008
Posts: 2
Location: Wuhan,China
|
|
|
|
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 |
|
|
ofer71
Global Moderator
Joined: 27 Dec 2005
Posts: 2358
Location: Israel
|
|
|
|
KEVINSAU -
In the mainframe world, the high value is usually the hexadecimal value 'FF'.
O. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
oops..I wanted to say..
| Quote: |
| And LOW-VALUE represents X'00'. |
apologies.. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| 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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| 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? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Douglas Wilder
Active User
.jpg)
Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL
|
|
|
|
| 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 |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL
|
|
|
|
| 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 |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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. |
|
| Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL
|
|
|
|
| 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 |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL
|
|
|
|
| In our cases the low-values x'00' were usually the leading zeroes in packed or binary numbers. |
|
| Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007
Posts: 631
Location: Wisconsin
|
|
|
|
| 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 |
|
|
KEVINSAU
New User
Joined: 16 Jan 2008
Posts: 2
Location: Wuhan,China
|
|
|
|
| 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.  |
|
| Back to top |
|
|
|
|
