Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
simple doubt 1
- Thread starter kurup
- Start date
move 123 to numeric-item, this moves the value +123 to your numeric field allowing comparisons such as
if numeric-field = 123...etc
move "123" to numeric-item, this is moving a literal (i.e a string) to your nueric-item field. This should result in an error as you can only move numeric values to numeric fields.
High values will differ depending on your platform, on an ebcidic platform (mainframes & midrange such as AS400), all characters are represented by a two character value. e.g the values 1 , 2, 3 etc are actually represented as F1, F2 and F3 in ebcidic. In EBCDIC, high values is the maximum value a single chracter can contain and is represented by FF, low values is represented by 00. It actually relates to hexadecimal (base 16 numbers where the values 0 - 15 are represented by 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E and F) which most of these machines use for storage (as opposed to binary on a PC).
Usually high values is good if you are finished reading a keyed file, and you wish to manually force an EOF. You simply move high values to the key and do another read, this should put you automatically at the EOF point. Similarly for low values, if you move low values to your key field before a read, you know that you will be at the very first record in the file.
if numeric-field = 123...etc
move "123" to numeric-item, this is moving a literal (i.e a string) to your nueric-item field. This should result in an error as you can only move numeric values to numeric fields.
High values will differ depending on your platform, on an ebcidic platform (mainframes & midrange such as AS400), all characters are represented by a two character value. e.g the values 1 , 2, 3 etc are actually represented as F1, F2 and F3 in ebcidic. In EBCDIC, high values is the maximum value a single chracter can contain and is represented by FF, low values is represented by 00. It actually relates to hexadecimal (base 16 numbers where the values 0 - 15 are represented by 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E and F) which most of these machines use for storage (as opposed to binary on a PC).
Usually high values is good if you are finished reading a keyed file, and you wish to manually force an EOF. You simply move high values to the key and do another read, this should put you automatically at the EOF point. Similarly for low values, if you move low values to your key field before a read, you know that you will be at the very first record in the file.
- Thread starter
- #3
-
1
- #5
Pipk,
call me an idiot, but have you ever seen any other number of bits in a byte then eight?
About the move (kurup's first ques):
If NUMERIC-ITEM is defined as zoned unsigned, moving the literal "123" most likely leeds to a correct value in that field. Whether such a move is accepted depends on the compiler used, but i suspect it will.
Regards,
Ronald.
call me an idiot, but have you ever seen any other number of bits in a byte then eight?
About the move (kurup's first ques):
If NUMERIC-ITEM is defined as zoned unsigned, moving the literal "123" most likely leeds to a correct value in that field. Whether such a move is accepted depends on the compiler used, but i suspect it will.
Regards,
Ronald.
I think that if you were to code MOVE "123" TO NUMERIC-ITEM and it is defined as a PIC 9(3), then you would get a compiler error, as you don't need quotes to move a number into a PIC 9 field. Just say MOVE 123 TO NUMERIC-ITEM. Then you can either display (or print) the value or else use it for comparing.
If NUMERIC-ITEM is defined as COMP or COMP-3, then you can't display it. Well, actually you can, but it looks rather strange; it doesn't display the actual number.
Now if somewhere along the way of program processing, you were to try and move a PIC X variable into a PIC 9, PIC 9 COMP, or PIC 9 COMP-3, then you get a "Sock 7," which is a data-exception error, and the whole thing blows up.
Hope this helps, Nina Too
If NUMERIC-ITEM is defined as COMP or COMP-3, then you can't display it. Well, actually you can, but it looks rather strange; it doesn't display the actual number.
Now if somewhere along the way of program processing, you were to try and move a PIC X variable into a PIC 9, PIC 9 COMP, or PIC 9 COMP-3, then you get a "Sock 7," which is a data-exception error, and the whole thing blows up.
Hope this helps, Nina Too
Nina,
i haven't tried, but as i said the compiler may decline moving a literal to a numeric field. whether it makes any sense doing so is a different discussion entirely.
I believe displaying any numeric field will show a readable figure; only signed comp-3 fields with negative values look a bit strange. For best control, using zoned or even better numeric-edited fields has my preference.
Moving an incorrect value to a numeric field, although you probably need to do it indirectly, won't render a S(0C7), a numeric move form that value or a mathematic operation or a test on it will.
Jack,
"... too sense ... " ?!!
Regards,
Ronald.
i haven't tried, but as i said the compiler may decline moving a literal to a numeric field. whether it makes any sense doing so is a different discussion entirely.
I believe displaying any numeric field will show a readable figure; only signed comp-3 fields with negative values look a bit strange. For best control, using zoned or even better numeric-edited fields has my preference.
Moving an incorrect value to a numeric field, although you probably need to do it indirectly, won't render a S(0C7), a numeric move form that value or a mathematic operation or a test on it will.
Jack,
"... too sense ... " ?!!
Regards,
Ronald.
Ronald, I'm not sure. On the compilers I've been using at work, when you try and do an arithmetic operation on a PIC X field, you get a compiler error. The compiler says that you are trying to do an arithmetic operation on a PIC X field -- it won't compile.
As for when I actually get a SOCK 7, it's been a bit since I've done batch processing; I work almost exclusively on CICS. And I use InterTest. And InterTest will stop you and broadcast an ASRA exception when you try and put a PIC X into a COMP or COMP-3 field. It won't let you go any further.
In our testing environment, we have InterTest monitoring key programs, and it will stop the processing automatically stepping in, even if you weren't logged into InterTest; it just suddenly comes up and stops the processing. I know because it happened to me recently when I was debugging a problem.
But I do remember getting SOCK 7's when I was doing batch processing. And as I recall, it was when I was trying to move a PIC X into a COMP or COMP-3 field. The compiler didn't pick this up.
Please advise, Nina Too
As for when I actually get a SOCK 7, it's been a bit since I've done batch processing; I work almost exclusively on CICS. And I use InterTest. And InterTest will stop you and broadcast an ASRA exception when you try and put a PIC X into a COMP or COMP-3 field. It won't let you go any further.
In our testing environment, we have InterTest monitoring key programs, and it will stop the processing automatically stepping in, even if you weren't logged into InterTest; it just suddenly comes up and stops the processing. I know because it happened to me recently when I was debugging a problem.
But I do remember getting SOCK 7's when I was doing batch processing. And as I recall, it was when I was trying to move a PIC X into a COMP or COMP-3 field. The compiler didn't pick this up.
Please advise, Nina Too
Nina,
You're right; a compiler can detect illegal operations, like an arithmetic operation on a PIC X field. MOVEing a value, any value, to a numeric field can't be detected by the compiler and will therefore compile without a hitch. On runtime however, incorrect values in numeric fields (at least binary and packed-decimal) result in S(0C7) abends.
By the way, that is one nifty testing tool you guys use ! As i understand, it catches abends such as the S(0C7) before they occur; nice ...
Anyway, i work mainly in a batch environment, so i have to plough through job output to find any errors.
Regards,
Ronald.
P.S. A S(0C7) is not a garment, but a System abend, number 0C7 ...
)
You're right; a compiler can detect illegal operations, like an arithmetic operation on a PIC X field. MOVEing a value, any value, to a numeric field can't be detected by the compiler and will therefore compile without a hitch. On runtime however, incorrect values in numeric fields (at least binary and packed-decimal) result in S(0C7) abends.
By the way, that is one nifty testing tool you guys use ! As i understand, it catches abends such as the S(0C7) before they occur; nice ...
Anyway, i work mainly in a batch environment, so i have to plough through job output to find any errors.
Regards,
Ronald.
P.S. A S(0C7) is not a garment, but a System abend, number 0C7 ...
)RonaldB - There are (were?) machines that did not use 8-bit bytes. One that comes immediately to mind is the DEC 1099. This was a large DEC mainframe that generally ran the TOPS-10 Operating System. Its native word size was 36 bits (the mathematicians loved it because of the increased precision of its floating point arithmetic due to the larger word size).
When programming in COBOL on this machine you could use 5 7-bit ASCII bytes per word or six 6-bit coded bytes per word (I suspect it also supported 8-bit bytes, but don't remember for sure.). Definitely strange, but, COBOL was flexible enough to deal with it quite well.
When programming in COBOL on this machine you could use 5 7-bit ASCII bytes per word or six 6-bit coded bytes per word (I suspect it also supported 8-bit bytes, but don't remember for sure.). Definitely strange, but, COBOL was flexible enough to deal with it quite well.
Guest_imported
New member
- Jan 1, 1970
- 0
1> If you DISPLAY a packed decimal field, the compiler will convert it to displayable numbers, EXCEPT that negative numbers will have the last digit prinbted as whatever character has the overpunch.
2> Honeywell used to have an octal mainframe, which had six-bit bytes. There IS a 6-bit ASCII code...
Stephen J Spiro
Member, J4 COBOL Standards Committee
stephenjspiro at hotmail.com
2> Honeywell used to have an octal mainframe, which had six-bit bytes. There IS a 6-bit ASCII code...
Stephen J Spiro
Member, J4 COBOL Standards Committee
stephenjspiro at hotmail.com
RonaldB wrote:
-------------
By the way, that is one nifty testing tool you guys use ! As i understand, it catches abends such as the S(0C7) before they occur; nice ...
Anyway, i work mainly in a batch environment, so i have to plough through job output to find any errors.
-------------
I used to work at a company where we had all sorts of neat tools for CICS. We had InterTest, then switched to Xpeditor Online, so I got to learn both. But they didn't have the 'monitor' thing set, so there were all sorts of online abendings happening.
One time, I wrote a program which read error messages from a Temporary Storage Queue (TSQ) and was supposed to display these on a CICS map. Well, unfortunately, the TSQ contained all sorts of undisplayable characters. The first time I ran the program, using Xpeditor (which we had switched to), the thing went KABOOM!!!! I had to go outside of the region and do a forced ending of the task to get me out of that mess.
But when doing batch, we had no test tools at all. We had to write test displays into test versions of each batch program, then run the job just to get the display.
At my (relatively, as of 4 months) new job, we have Xpeditor for batch. Have you heard of that, and do you use it? I haven't done any batch programming here though I've written a couple of JCL's to run utilities. I was hired as a CICS "expert" (ha!).
They use InterTest for online applications. And I found out about the InterTest monitoring system one day when I was running an application in our test environment, just to find out a bit more about it. All of a sudden, InterTest appeared with an ASRA Exception message. It is a good tool to have. Don't know if Xpeditor for batch has any similar sort of tool.
Nina Too
-------------
By the way, that is one nifty testing tool you guys use ! As i understand, it catches abends such as the S(0C7) before they occur; nice ...
Anyway, i work mainly in a batch environment, so i have to plough through job output to find any errors.
-------------
I used to work at a company where we had all sorts of neat tools for CICS. We had InterTest, then switched to Xpeditor Online, so I got to learn both. But they didn't have the 'monitor' thing set, so there were all sorts of online abendings happening.
One time, I wrote a program which read error messages from a Temporary Storage Queue (TSQ) and was supposed to display these on a CICS map. Well, unfortunately, the TSQ contained all sorts of undisplayable characters. The first time I ran the program, using Xpeditor (which we had switched to), the thing went KABOOM!!!! I had to go outside of the region and do a forced ending of the task to get me out of that mess.
But when doing batch, we had no test tools at all. We had to write test displays into test versions of each batch program, then run the job just to get the display.
At my (relatively, as of 4 months) new job, we have Xpeditor for batch. Have you heard of that, and do you use it? I haven't done any batch programming here though I've written a couple of JCL's to run utilities. I was hired as a CICS "expert" (ha!).
They use InterTest for online applications. And I found out about the InterTest monitoring system one day when I was running an application in our test environment, just to find out a bit more about it. All of a sudden, InterTest appeared with an ASRA Exception message. It is a good tool to have. Don't know if Xpeditor for batch has any similar sort of tool.
Nina Too
- Status
Similar threads