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!
Compute Error 4
- Thread starter claudeb
- Start date
- Thread starter
- #2
-
1
- #4
- Thread starter
- #5
-
1
- #6
-
1
- #7
-
1
- #8
StephenJSpiro
Programmer
If you are going to give us pieces of code, please at least present it so that it makes sense. The way you showed it, NEW was a field in C, and B was not part of a table. Also, you gave no indication of what values were in A (or A-N) or B. Or what values were supposed to be there. Your code didn't work until you replaced the spaces with zeros because you cannot add spaces; we have no idea what was in B.
Stephen J Spiro
Stephen J Spiro
Claude,
The initialize may have stopped the "error" but it may not have solved the problem; worse, it may have "caused" problems that haven't happened yet (the worst kind). It's like changing lanes w/o looking into the rearview mirror.
Why would you have spaces in a numeric fld? What does changing the space(s) do to the value of the fld? If the spaces represent a tbl fld that hasn't been filled, the more efficient solution may be to stop the search when the fld = spaces (this depends on how the tbl is populated. An alt is to init the tbl using zeros for this fld.
Regards, Jack.
The initialize may have stopped the "error" but it may not have solved the problem; worse, it may have "caused" problems that haven't happened yet (the worst kind). It's like changing lanes w/o looking into the rearview mirror.
Why would you have spaces in a numeric fld? What does changing the space(s) do to the value of the fld? If the spaces represent a tbl fld that hasn't been filled, the more efficient solution may be to stop the search when the fld = spaces (this depends on how the tbl is populated. An alt is to init the tbl using zeros for this fld.
Regards, Jack.
Guest_imported
New member
- Jan 1, 1970
- 0
Hello,
In some compilers like RMCobol, it is better to zeroies the
table which include counter before u use it.
In some compilers like RMCobol, it is better to zeroies the
table which include counter before u use it.
- Thread starter
- #11
i am overwhelmed by your interest. my "duty" these days is to produce a sequentiel file to one of our consultants. they need some information (not all) about our clients.
one of the files i am reading stores the client's charge rate. For some reason, this code rate is defined as a pic x(02) at the establishment of the policy. In order to know the actual rate charge, i have to add the age of my client to the rate code (witch is the number of years since the policy has been changed or issued). I have no control on these fields. i can't change them, the whole system depends on them.
Now , for each policy, and then for each coverage, i have to produce the rate code. Yes, the field "B" is part of a table. field "NEW" is not related to fild "C".
Well, it is much simpler than it seems.
I think that every thing works just fine (for now). I hope i have been clear.
It took me a long time to answer; i am sorry for that. i hope from one crisis to another, in other words, i have been extremely busy these days. Thanks.
one of the files i am reading stores the client's charge rate. For some reason, this code rate is defined as a pic x(02) at the establishment of the policy. In order to know the actual rate charge, i have to add the age of my client to the rate code (witch is the number of years since the policy has been changed or issued). I have no control on these fields. i can't change them, the whole system depends on them.
Now , for each policy, and then for each coverage, i have to produce the rate code. Yes, the field "B" is part of a table. field "NEW" is not related to fild "C".
Well, it is much simpler than it seems.
I think that every thing works just fine (for now). I hope i have been clear.
It took me a long time to answer; i am sorry for that. i hope from one crisis to another, in other words, i have been extremely busy these days. Thanks.
Concerning your incoming PIC X field (which is used throughout the system), I can "feel your pain" 
Because frequently CICS map fields, defined by the BMS mapping utility, put everything into a PIC X format, including numerical items. And if you are using a Client-Server architecture with a GUI as your "map," the fields being fed to the interface for the GUI might have to be PIC X.
Using BMS mapping in CICS, you can designate a field as "numeric only" (which will put it into a PIC 9). But then whichever program is doing the screen displays has to get rid of any extraneous zeroes. YOu can't change them into spaces because (my compiler at any rate) won't let me put spaces into a PIC 9 field. So whoever is handling the screen display has to set an attribute of "dark" for the extraneous zeroes. But you have to be careful with this because you don't want necessary zeroes to be darkened-out. This can be a royal pain.
It looks as though you found the solution. Redefine the incoming PIC X field, then change the spaces to zeroes. But you have to make sure that you don't change the value of this incoming field by adding zeroes in places where this might happen i.e. "5 " (representing $5) doesn't become "5000" (which would represent $5000).
Hope this helps, NIna Too
Because frequently CICS map fields, defined by the BMS mapping utility, put everything into a PIC X format, including numerical items. And if you are using a Client-Server architecture with a GUI as your "map," the fields being fed to the interface for the GUI might have to be PIC X.
Using BMS mapping in CICS, you can designate a field as "numeric only" (which will put it into a PIC 9). But then whichever program is doing the screen displays has to get rid of any extraneous zeroes. YOu can't change them into spaces because (my compiler at any rate) won't let me put spaces into a PIC 9 field. So whoever is handling the screen display has to set an attribute of "dark" for the extraneous zeroes. But you have to be careful with this because you don't want necessary zeroes to be darkened-out. This can be a royal pain.
It looks as though you found the solution. Redefine the incoming PIC X field, then change the spaces to zeroes. But you have to make sure that you don't change the value of this incoming field by adding zeroes in places where this might happen i.e. "5 " (representing $5) doesn't become "5000" (which would represent $5000).
Hope this helps, NIna Too
StephenJSpiro
Programmer
NinaToo said:
"Using BMS mapping in CICS, you can designate a field as "numeric only" (which will put it into a PIC 9). But then whichever program is doing the screen displays has to get rid of any extraneous zeroes. YOu can't change them into spaces because (my compiler at any rate) won't let me put spaces into a PIC 9 field. So whoever is handling the screen display has to set an attribute of "dark" for the extraneous zeroes. But you have to be careful with this because you don't want necessary zeroes to be darkened-out. This can be a royal pain."
You can specify PICOUT as well as PICIN on your BMS map. You can have PICIN='9(5)' and also PICOUT='x(5)' INITIAL=SPACES or INITIAL=LOW-VAlUES. Or, you can make it PICOUT='ZZZZ9', which I think is what you are trying to do.
Stephen J Spiro
"Using BMS mapping in CICS, you can designate a field as "numeric only" (which will put it into a PIC 9). But then whichever program is doing the screen displays has to get rid of any extraneous zeroes. YOu can't change them into spaces because (my compiler at any rate) won't let me put spaces into a PIC 9 field. So whoever is handling the screen display has to set an attribute of "dark" for the extraneous zeroes. But you have to be careful with this because you don't want necessary zeroes to be darkened-out. This can be a royal pain."
You can specify PICOUT as well as PICIN on your BMS map. You can have PICIN='9(5)' and also PICOUT='x(5)' INITIAL=SPACES or INITIAL=LOW-VAlUES. Or, you can make it PICOUT='ZZZZ9', which I think is what you are trying to do.
Stephen J Spiro
StephenJSpiro
Programmer
Nina, look at the COBOL map; the Output Map actually redefines the whole Input Map. The PICOUT will be in the redefined map at the appropriate offset. If you know Assembler, you can do additional redefines. I forget the exact code; I haven't done it in a while.
Stephen J Spiro
Stephen J Spiro
Stephen, yes I'm aware that the PICOUT is a redefine of the PICIN.
But as I recall, when the PICIN is defined as a PIC X, then so is the PICOUT. So this answers my question. The actual re-defining comes when certain fields (length and flag bytes) in the PICIN are redefined as attribute bytes and as a filler in the PICOUT.
One can further redefine, using COBOL, the map copybook using regular code after the "copy [mapname]" statement in Working Storage. For instance, when using BMS, it will only allow me to define a 1-dimensional array. So so to get a 2-dimensional array -- for a set of display fields which have Y columns in X rows -- I have to code a redefine of the PICOUT to get my 2-dimensional table. I code in fillers in appropriate places so that the redefined table contains the same number of bytes and is laid out in the same way as the original 1-dimensional table.
And if a programmer wanted to redefine a PICIN/PICOUT X field as a PIC 9, this redefining technique that I described above can be used.
Nina Too
But as I recall, when the PICIN is defined as a PIC X, then so is the PICOUT. So this answers my question. The actual re-defining comes when certain fields (length and flag bytes) in the PICIN are redefined as attribute bytes and as a filler in the PICOUT.
One can further redefine, using COBOL, the map copybook using regular code after the "copy [mapname]" statement in Working Storage. For instance, when using BMS, it will only allow me to define a 1-dimensional array. So so to get a 2-dimensional array -- for a set of display fields which have Y columns in X rows -- I have to code a redefine of the PICOUT to get my 2-dimensional table. I code in fillers in appropriate places so that the redefined table contains the same number of bytes and is laid out in the same way as the original 1-dimensional table.
And if a programmer wanted to redefine a PICIN/PICOUT X field as a PIC 9, this redefining technique that I described above can be used.
Nina Too
- Status
Similar threads
- Locked
- Question
- Locked
- Question