Given the code below - I get an ' invalid MOVE statement ' error - is it possible to move the contents of the float-long item to another field for display purposes - and if so - how ??.
You may want to use a floating-point edited item, to do so use a PICTURE with the following rules (per COBOL2014):
consist of two parts, separated without any spaces, by the symbol 'E' (the first part represents the significand; the second part represents the exponent)
the significand shall be a valid character-string for either a numeric item or a numeric-edited item for a fixed-point result without floating insertion editing or zero suppression
the exponent shall be ‘+9’, ‘+99’, ‘+999’, ‘+9999’, or ‘+9(n)’ where n = 1, 2, 3, or 4
As always: Please share your result:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you create a filed say as pic s9(8).9(5) then move to to there it
will display corectly with leaving zeros shown or as pic z(7)9.9(4) to space fill leading zeros.
You cannot move native numeric fields to Alpha or Alphanumeric.
👍
1
Last edit: Simon Sobisch 2021-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vincent - I understand what you say - BUT I don't want to 'display' it.
It's confusing that the cross reference program describes the float-long as s9(17)v9(17) - so I don;'t understand why that can't be moved directly to an alphanum field.
I have a common routine in a program that takes 'ANY' data item and writes it's content to a trace file - And since I don't really know what 'type' of data item that is - I 'move' the data from it's original field to an Alpha field.
The majority of times this works fine - but this Float-Long crashed because in order to show the data correctly - I move numeric fields containing a V 'implied decimal' to an identical field containing a '.' - which the compiler doesn't like if the field is signed, which float-long is.
I've sort of fixed it by checking for a float-long in the data description & moving it to a 9(17).9(17) and dropping the sign - this then is able to be moved to the alpha field.
Better than ignoring it completely I suppose.
Thanks anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given the code below - I get an ' invalid MOVE statement ' error - is it possible to move the contents of the float-long item to another field for display purposes - and if so - how ??.
Last edit: Simon Sobisch 2021-11-28
You can directly DISPLAY the float item.
You may want to use a floating-point edited item, to do so use a
PICTUREwith the following rules (per COBOL2014):As always: Please share your result:
I'll have to investigate that - I haven't worked with floating point stuff (ever). Thanks.
If you create a filed say as pic s9(8).9(5) then move to to there it
will display corectly with leaving zeros shown or as
pic z(7)9.9(4)to space fill leading zeros.You cannot move native numeric fields to Alpha or Alphanumeric.
Last edit: Simon Sobisch 2021-11-28
Vincent - I understand what you say - BUT I don't want to 'display' it.
It's confusing that the cross reference program describes the float-long as s9(17)v9(17) - so I don;'t understand why that can't be moved directly to an alphanum field.
I have a common routine in a program that takes 'ANY' data item and writes it's content to a trace file - And since I don't really know what 'type' of data item that is - I 'move' the data from it's original field to an Alpha field.
The majority of times this works fine - but this Float-Long crashed because in order to show the data correctly - I move numeric fields containing a V 'implied decimal' to an identical field containing a '.' - which the compiler doesn't like if the field is signed, which float-long is.
I've sort of fixed it by checking for a float-long in the data description & moving it to a 9(17).9(17) and dropping the sign - this then is able to be moved to the alpha field.
Better than ignoring it completely I suppose.
Thanks anyway.