Problem with Fujitsu Cobol
Geoff
Hi All
I am having a little problem with Fujitsu Cobol.
I am working through TY Cobol in 21 days and working through the exercises.
In one there is an iput field declared as
01 ENTRY-FIELD PIC ZZZ,ZZZ,ZZZ.ZZ.
Later this field is used in ACCEPT ENTRY-FIELD.
When I try to compile the program, I get the error message
JMN3053I-S IN ACCEPT STATEMENT SPECIFYING MNEMONIC-NAME OR
FUNCTION-NAME,IDENTIFIER 'ENTRY-FIELD' MUST BE FIXED-LENGTH GROUP
ITEM,ALPHABETIC,ALPHANUMERIC,OR EXTERNAL DECIMAL ITEM.
Any ideas to what I am doing wrong
TIA
Geoff Badger
docd...@clark.net
In article <889041681.17834.0...@news.demon.co.uk>,
I am not familiar w/ Fujitsu but the error-message is clear enough,
almost... PIC ZZZ,ZZZ,ZZZ.ZZ is fixed-length, true, but it is not
alphabetic, alphanumeric or external decimal.
(freebie Tip From The Pros: in dealing with zero-suppression it is
considered Most Professional to leave at least *one* digit as a display
numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
blank and someone of Great Importance will say 'Hey, why did you skip this
field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
DD
Jim K
Geoff wrote:
>
> Hi All
> I am having a little problem with Fujitsu Cobol.
> I am working through TY Cobol in 21 days and working through the exercises.
> In one there is an iput field declared as
> 01 ENTRY-FIELD PIC ZZZ,ZZZ,ZZZ.ZZ.
> Later this field is used in ACCEPT ENTRY-FIELD.
> When I try to compile the program, I get the error message
> JMN3053I-S IN ACCEPT STATEMENT SPECIFYING MNEMONIC-NAME OR
> FUNCTION-NAME,IDENTIFIER 'ENTRY-FIELD' MUST BE FIXED-LENGTH GROUP
> ITEM,ALPHABETIC,ALPHANUMERIC,OR EXTERNAL DECIMAL ITEM.
> Any ideas to what I am doing wrong
> TIA
> Geoff Badger
Look at your error message. Is it fixed length? Yes
Now, is it a group item?
Is it Alphabetic?
Is it alphanumeric?
Is it an external decimal item?
When you have answered these questions, you will have the answer to your
problem.
Good luck,
Jim K.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
"The important thing is to stop lying to yourself. A man
who lies to himself, and believes his own lies, becomes
unable to recognize the truth, either in himself or in
anyone else, and he ends up losing respect for himself
as well as for others. When he has no respect for anyone,
he can no longer love and, in order to divert himself,
having no love in him, he yields to his impulses, indulges
in the lowest forms of pleasure, and behaves in the end
like an animal, in satisfying his vices.
And it all comes from lying -- lying to others and to yourself."
--Feodor Mikhailovich Dostoyevsky from his 1880 work,
"The Brothers Karamazov"
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Skippy PB
On 4 Mar 1998 20:39:58 GMT, docd...@clark.net () wrote:
>In article <889041681.17834.0...@news.demon.co.uk>,
>Geoff <ge...@pondeset.demon.co.uk> wrote:
>>Hi All
>>I am having a little problem with Fujitsu Cobol.
>>I am working through TY Cobol in 21 days and working through the exercises.
>>In one there is an iput field declared as
>>01 ENTRY-FIELD PIC ZZZ,ZZZ,ZZZ.ZZ.
>>Later this field is used in ACCEPT ENTRY-FIELD.
>>When I try to compile the program, I get the error message
>>JMN3053I-S IN ACCEPT STATEMENT SPECIFYING MNEMONIC-NAME OR
>>FUNCTION-NAME,IDENTIFIER 'ENTRY-FIELD' MUST BE FIXED-LENGTH GROUP
>>ITEM,ALPHABETIC,ALPHANUMERIC,OR EXTERNAL DECIMAL ITEM.
>>Any ideas to what I am doing wrong
>>TIA
>>Geoff Badger
>
>I am not familiar w/ Fujitsu but the error-message is clear enough,
>almost... PIC ZZZ,ZZZ,ZZZ.ZZ is fixed-length, true, but it is not
>alphabetic, alphanumeric or external decimal.
>
>(freebie Tip From The Pros: in dealing with zero-suppression it is
>considered Most Professional to leave at least *one* digit as a display
>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
>blank and someone of Great Importance will say 'Hey, why did you skip this
>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
>
>DD
>
True statement. PIC ZZZ,ZZZ,ZZZ.ZZ is a numeric edited field and
can't be used in an ACCEPT statement. It can, however, be used in a
DISPLAY statement.
////
(o o)
-oOO--(_)--OOo-
Here's Looking at ya!
Steve
The Programmer
docd...@clark.net wrote in message <6dke6u$1...@clarknet.clark.net>...
>
[...snip...]
>(freebie Tip From The Pros: in dealing with zero-suppression it is
>considered Most Professional to leave at least *one* digit as a display
>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
>blank and someone of Great Importance will say 'Hey, why did you skip this
>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
>
>DD
>
Welllllll... actually, DD, depending on the report, it *is* sometimes better
to suppress zeros. I remember once I had to create a report formatted
something like a spreadsheet, where the item labels ran down the left side,
and the categories run across the top. In that case, it was easier for the
end user if the zero value 'cells' were left blank, so they could more
easily pick out those items where the categories didn't have a zero value.
Judson McClendon
Skippy PB <stev...@apk.net> wrote:
>
> True statement. PIC ZZZ,ZZZ,ZZZ.ZZ is a numeric edited field and
> can't be used in an ACCEPT statement. It can, however, be used in a
> DISPLAY statement.
PIC ZZZ,ZZZ,ZZZ.ZZ can be used with Micro Focus COBOL in an ACCEPT
statement. I use PICs like that in screens all the time. I believe
"TY COBOL in 21 Days" is based on MF COBOL. My feeling is that it is
a bit dumb for a compiler to allow DISPLAY of a PIC that it will not
allow on ACCEPT. After all, the essential purpose of screens is to
allow data entry. You could present such data by using DISPLAY alone,
even without the SCREEN SECTION. Barring a standard, though, we can
expect a lot of variation in how these things are implemented. The
latest draft standard does include screens. There are a few issues
the draft standard doesn address as well as I would like, but at least
screens are finally in there.
--
Judson McClendon This is a faithful saying and worthy of all
Sun Valley Systems acceptance, that Christ Jesus came into the
judm...@mindspring.com world to save sinners (1 Timothy 1:15)
(please remove zzz from email id to respond)
Geoff
DD
Tried that - still the same problem.
I agree with your tip, and would normally do this, but as I said I am
worging through someone else's "Un-Professional exercises"
>Geoff <ge...@pondeset.demon.co.uk> wrote:
>>Hi All
>>I am having a little problem with Fujitsu Cobol.
>>I am working through TY Cobol in 21 days and working through the
exercises.
>>In one there is an iput field declared as
>>01 ENTRY-FIELD PIC ZZZ,ZZZ,ZZZ.ZZ.
>>Later this field is used in ACCEPT ENTRY-FIELD.
>>When I try to compile the program, I get the error message
>>JMN3053I-S IN ACCEPT STATEMENT SPECIFYING MNEMONIC-NAME OR
>>FUNCTION-NAME,IDENTIFIER 'ENTRY-FIELD' MUST BE FIXED-LENGTH GROUP
>>ITEM,ALPHABETIC,ALPHANUMERIC,OR EXTERNAL DECIMAL ITEM.
>>Any ideas to what I am doing wrong
>>TIA
>>Geoff Badger
>
>I am not familiar w/ Fujitsu but the error-message is clear enough,
>almost... PIC ZZZ,ZZZ,ZZZ.ZZ is fixed-length, true, but it is not
>alphabetic, alphanumeric or external decimal.
>
docd...@clark.net
In article <34fec...@news1.ibm.net>,
The Programmer <som...@someplace.com> wrote:
>docd...@clark.net wrote in message <6dke6u$1...@clarknet.clark.net>...
>>
>
>>(freebie Tip From The Pros: in dealing with zero-suppression it is
>>considered Most Professional to leave at least *one* digit as a display
>>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
>>blank and someone of Great Importance will say 'Hey, why did you skip this
>>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
>>
>>DD
>>
>
>to suppress zeros. I remember once I had to create a report formatted
>something like a spreadsheet, where the item labels ran down the left side,
>and the categories run across the top. In that case, it was easier for the
>end user if the zero value 'cells' were left blank, so they could more
>easily pick out those items where the categories didn't have a zero value.
Really, old boy... and how many years were you writing reports before this
happened for the first time?... and how many between that and the second?
Granted, one can find an instance to support any assertion BUT... tell us,
prithee, how your example invalidates my original assertion of ' in
dealing with zero-suppression it is considered Most Professional to leave
at least *one* digit as a display numeric'.
Remember... *first* the rules, *then* the exceptions.
DD
docd...@clark.net
In article <889115991.24001.0...@news.demon.co.uk>,
Tried what, using Z9.99? Of course it will give you the same problem,
anything with a Z is not alphabetic, alphanumeric or external decimal; my
'hint' was FFU (For Future Use)
DD
>I agree with your tip, and would normally do this, but as I said I am
>worging through someone else's "Un-Professional exercises"
>docd...@clark.net wrote in message <6dke6u$1...@clarknet.clark.net>...
>>In article <889041681.17834.0...@news.demon.co.uk>,
>>Geoff <ge...@pondeset.demon.co.uk> wrote:
>>>Hi All
>>>I am having a little problem with Fujitsu Cobol.
>>>I am working through TY Cobol in 21 days and working through the
>exercises.
>>>In one there is an iput field declared as
>>>01 ENTRY-FIELD PIC ZZZ,ZZZ,ZZZ.ZZ.
>>>Later this field is used in ACCEPT ENTRY-FIELD.
>>>When I try to compile the program, I get the error message
>>>JMN3053I-S IN ACCEPT STATEMENT SPECIFYING MNEMONIC-NAME OR
>>>FUNCTION-NAME,IDENTIFIER 'ENTRY-FIELD' MUST BE FIXED-LENGTH GROUP
>>>ITEM,ALPHABETIC,ALPHANUMERIC,OR EXTERNAL DECIMAL ITEM.
>>>Any ideas to what I am doing wrong
>>>TIA
>>>Geoff Badger
>>
>>I am not familiar w/ Fujitsu but the error-message is clear enough,
>>almost... PIC ZZZ,ZZZ,ZZZ.ZZ is fixed-length, true, but it is not
>>alphabetic, alphanumeric or external decimal.
>>
Codes4Food
>>
> [...snip...]
>
>>(freebie Tip From The Pros: in dealing with zero-suppression it is
>>considered Most Professional to leave at least *one* digit as a display
>>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
>>blank and someone of Great Importance will say 'Hey, why did you skip this
>>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
>>
>>DD
>>
>
>Welllllll... actually, DD, depending on the report, it *is* sometimes better
>to suppress zeros. I remember once I had to create a report formatted
>something like a spreadsheet, where the item labels ran down the left side,
>and the categories run across the top. In that case, it was easier for the
>end user if the zero value 'cells' were left blank, so they could more
>easily pick out those items where the categories didn't have a zero value.
>
Yes, this is true for many reporting apps--by user/client request. They'd
rather see a blank
space than 0.00 cluttering the report fields.
It's more esthetic.
Codes4Food
>Subject: Re: Problem with Fujitsu Cobol
>From: docd...@clark.net ()
>Date: Thu, Mar 5, 1998 11:53 EST
>Message-id: <6dml9f$h...@clarknet.clark.net>
>>
>>>(freebie Tip From The Pros: in dealing with zero-suppression it is
>>>considered Most Professional to leave at least *one* digit as a display
>>>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
>>>blank and someone of Great Importance will say 'Hey, why did you skip this
>>>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
>>>
>>>DD
>>>
>>
>>Welllllll... actually, DD, depending on the report, it *is* sometimes better
>>to suppress zeros. I remember once I had to create a report formatted
>>something like a spreadsheet, where the item labels ran down the left side,
>>and the categories run across the top. In that case, it was easier for the
>>end user if the zero value 'cells' were left blank, so they could more
>>easily pick out those items where the categories didn't have a zero value.
>
>happened for the first time?... and how many between that and the second?
>Granted, one can find an instance to support any assertion BUT... tell us,
>
>Remember... *first* the rules, *then* the exceptions.
>
>DD
If the client/user requests the report in this
manner, then assuming you still wish
to continue receiving payment for services
rendered--a nasty little habit spending on non-
essentials like food, clothing and shelter pops
to mind, then you zero suppress EVERYTHING
they want.
Plus, how many published financial and
accounting reports use '0.00'?
The Goobers
Point well taken, old boy, but that is already covered by DocDwarf's Law
of Well-Functioning Systems, viz. -
'A Well-Functioning System is one which causes the person who has the
most say over signing the checks to smile.'
>
> Plus, how many published financial and
> accounting reports use '0.00'?
And, of course, how much of a programmer's work is for 'publication'?
Most of it is for in-house consumption, big hurkin' stacks o' greenbar
which are used as status-symbols. I would say that the Z9.99 'rule'
(which I just made up, saying that all PIC Z(n) fields should, unless
specifically requested otherwise, should be terminated with 9s starting
from the leftmost decimal position) serves the same purpose as the
self-contradicting legend THIS PAGE LEFT INTENTIONALLY BLANK... and, as
with any rule, there are exceptions... which usually wind up proving the
rule anyhow.
DD
The Goobers
Codes4Food wrote:
>
> >>
> > [...snip...]
> >
> >>(freebie Tip From The Pros: in dealing with zero-suppression it is
> >>considered Most Professional to leave at least *one* digit as a display
> >>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
> >>blank and someone of Great Importance will say 'Hey, why did you skip this
> >>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
> >>
> >>DD
> >>
> >
> >Welllllll... actually, DD, depending on the report, it *is* sometimes better
> >to suppress zeros. I remember once I had to create a report formatted
> >something like a spreadsheet, where the item labels ran down the left side,
> >and the categories run across the top. In that case, it was easier for the
> >end user if the zero value 'cells' were left blank, so they could more
> >easily pick out those items where the categories didn't have a zero value.
> >
>
> rather see a blank
> space than 0.00 cluttering the report fields.
> It's more esthetic.
Our experiences are obviously different and we have formed different
responses to them... but hey, if one wants only agreement then one
should speak only to one's mirror.
DD
Geoff
Hi All
I finally got the prog to compile by declaring the input field as
S999999V99.
Thanks for your help
Geoff
The Goobers
That might be because a field defined with a Z is an edited numeric...
not alphabetic, alphanumeric or external decimal.
DD
John L. Mindock
Codes4Food wrote:
>
> >>
> > [...snip...]
> >
> >>(freebie Tip From The Pros: in dealing with zero-suppression it is
> >>considered Most Professional to leave at least *one* digit as a display
> >>numeric; if the number in ENTRY-FIELD is 0.00 then that field will show up
> >>blank and someone of Great Importance will say 'Hey, why did you skip this
> >>field?' *Much* better is ZZZ,ZZZ,ZZ9.99)
> >>
> >>DD
> >>
> >
> >Welllllll... actually, DD, depending on the report, it *is* sometimes better
> >to suppress zeros. I remember once I had to create a report formatted
> >something like a spreadsheet, where the item labels ran down the left side,
> >and the categories run across the top. In that case, it was easier for the
> >end user if the zero value 'cells' were left blank, so they could more
> >easily pick out those items where the categories didn't have a zero value.
> >
>
> Yes, this is true for many reporting apps--by user/client request. They'd
> rather see a blank
> space than 0.00 cluttering the report fields.
> It's more esthetic.
There's a BLANK WHEN ZERO clause you can stuff in after the PIC that
I've used in the past. I think that it applies to fields masked as
Z(n)9.99. Been a long time since I used it and I can't test right now.
It may be that said clause is only part of IBM's REPORT WRITER. Anybody
got any memory pills out there (I forgot mine) :)?
John
Don Nelson
John L. Mindock wrote:
> There's a BLANK WHEN ZERO clause you can stuff in after the PIC that
> I've used in the past. I think that it applies to fields masked as
> Z(n)9.99. Been a long time since I used it and I can't test right now.
> It may be that said clause is only part of IBM's REPORT WRITER. Anybody
> got any memory pills out there (I forgot mine) :)?
BLANK WHEN ZERO is part of normal COBOL and can be specified on any item
of usage display that has a PICTURE describing it as numeric or
numeric-edited. It has nothing to do with IBM, report writer, PIC Z...
or whatever. Better replenish those memory pills. Actually, I need
some too most of the time.
--
Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, NCITS J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
don.n...@tandem.com
No clever quotes here
RandallBart
Don Nelson wrote:
> BLANK WHEN ZERO is part of normal COBOL and can be specified on any item
> of usage display that has a PICTURE describing it as numeric or
> numeric-edited.
I believe if the PIC is numeric (non-edited) the BLANK WHEN ZERO clause
makes it a numeric-edited field. At least that's how we implemented it.
--
I |\ Randall Bart mailto:Bart...@usa.spam.net
L |/
o |\ Bart...@worldnet.att.spam.net Bart...@hotmail.spam.com
v | \ 1-310-542-6013 Please reply without spam
e |\
Y |/ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00
o |\ The puzzle too hard for human beings:
u |/ http://members.aol.com/PanicYr00/Sequence.html
William M. Klein
RandallBart wrote in message <6ecu2f$4...@bgtnsc03.worldnet.att.net>...
I wasn't going to comment on this, but the issue of BLANK WHEN ZERO with
otherwise numeric (rather than numeric-edited) items actually caused a
slight 'nightmare' for J4 within the last few years. I think the draft
Standard has "fixed' the problem by saying that this isn't allowed - but I
haven't checked it recently. The reason that it should be "illegal" is
examples like
Pic S9V99 (what about the "S')
Pic 99pp (the mind boggles about what spaces means)
on the other hand, this means that
Pic 99 Blank when Zero
is also illegal (I think) and that too has some interesting implications.
--
+ +
+ Bill Klein -
"C" is a nice letter to START the name of your programming language
with
but I wouldn't want to end up there.
RandallBart
William M. Klein wrote:
> I wasn't going to comment on this, but the issue of BLANK WHEN ZERO with
> otherwise numeric (rather than numeric-edited) items actually caused a
> slight 'nightmare' for J4 within the last few years. I think the draft
> Standard has "fixed' the problem by saying that this isn't allowed - but I
> haven't checked it recently. The reason that it should be "illegal" is
> examples like
>
> Pic S9V99 (what about the "S')
No problem. The field contains it's normal signed data, except it
contains " " when it would otherwise be "00{" (or "{00" if your signs
are leading).
> Pic 99pp (the mind boggles about what spaces means)
No problem what space means: It means space where there's space to have
space. For the implied positions, logically they contain zeros (as
always) and physically they contain nothing (as always) because they
don't exist.
Th trouble comes when you move a small value to this field. If a value
between 1 and 99 is moved to that field, should we get "00" or " ". I
vote for " ", but I see justification for the other viewpoint.
>
> on the other hand, this means that
>
> Pic 99 Blank when Zero
>
> is also illegal (I think) and that too has some interesting implications.
This has to be legal, I know that it's in existing code.
As I said, the BLANK WHEN ZERO clause makes it an edited field, that's
the way it was implemented in A Series COBOL(68) and COBOL74, and I
believe it was documented that way on V Series. It probably said so in
the Burroughs corporate Cobol standard. It really hadn't occured to me
that the standard hadn't nailed this isssue down in decades past, but I
know PICs can be interesting. I remember working on the PIC parser in
the Cobol filter. We found plenty of unusual PIC strings that had been
accepted by one compiler or another. Is S99.99 valid? How about S99PP?
William M. Klein
I probably wasn't clear in my last post. The current ('85) and all previous
Standard have said exactly what this series is talking about, that you *can*
use BLANK WHEN ZERO with a numeric field and that it then turns a
numeric-field into a numeric-edited field.
The problem that this causes (and the reason the draft of the NEXT Standard
is changing this), is that this means that "S" and "P" and "V" are required
to be VALID in a numeric-edited field - while all the rules about what is
valid say they are not allowed. The rules about handling S,P, and V require
that comparisons (for example) must be done numerically - while the rules
for numeric-edited fields require that comparisons be done alphanumerically
(in most cases). There are a bunch of other problems with allowing fields
with these PICTURE characters to be "treated as numeric-edited" - and this
is something that J4 has relatively dealt with.
--
+ +
+ Bill Klein -
"C" is a nice letter to START the name of your programming language
with
but I wouldn't want to end up there.
RandallBart wrote in message <6eg2tm$f...@bgtnsc02.worldnet.att.net>...
Don Nelson
William M. Klein wrote:
>
> I probably wasn't clear in my last post. The current ('85) and all previous
> Standard have said exactly what this series is talking about, that you *can*
> use BLANK WHEN ZERO with a numeric field and that it then turns a
> numeric-field into a numeric-edited field.
>
> The problem that this causes (and the reason the draft of the NEXT Standard
> is changing this)
The draft is not changing this at all. There is no proposal on the
agenda (the only close one is zero suppression and locale editing) and
the rules haven't change much since the previous standard other than
being a bit garbled.
>is that this means that "S" and "P" and "V" are required
> to be VALID in a numeric-edited field - while all the rules about what is
> valid say they are not allowed. The rules about handling S,P, and V require
> that comparisons (for example) must be done numerically - while the rules
> for numeric-edited fields require that comparisons be done alphanumerically
> (in most cases). There are a bunch of other problems with allowing fields
> with these PICTURE characters to be "treated as numeric-edited" - and this
> is something that J4 has relatively dealt with.
>
Not that I can see. Perhaps I missed something. Anyhow, the field is
numeric-edited. This means that comparisons and all could care less
about Ps, Vs, and so on. It is just a string. For moving something to
it, the rule says you make it spaces if the input value is zero (they
don't say that very well). PIC 9PP means it ends up one space if you
move zero to it. There is an obvious problem with de-editing moves.
Anyhow, I'm writing a proposal to deal with some of this.
RandallBart
Don Nelson wrote:
>
> William M. Klein wrote:
> >
> > I probably wasn't clear in my last post. The current ('85) and all previous
> > Standard have said exactly what this series is talking about, that you *can*
> > use BLANK WHEN ZERO with a numeric field and that it then turns a
> > numeric-field into a numeric-edited field.
> >
> > The problem that this causes (and the reason the draft of the NEXT Standard
> > is changing this)
>
> The draft is not changing this at all. There is no proposal on the
> agenda (the only close one is zero suppression and locale editing) and
> the rules haven't change much since the previous standard other than
> being a bit garbled.
Do you mean the rules are being engarbled, degarbled, or just garbled
differently? (I suspect the latter.)
I became familiar with the gaps and contradictions in the definition of
the PIC clause back in 1985. I was working on BCT (Burroughs Cobol
Translator), which had gagged trying to count the size of a PIC S9999.99
and similar strings. The PIC section of the source language manuals
were mostly cribbed from X3.23-1968, and that was as clear as mud. We
reworked our PIC parser so that it would accept just about anything, but
we never were sure exactly what the spec said was legal. We even
accepted double signs (e g, -9999.99DB). Of course this was the
translator not the compiler, we needed to accept what ever came our
way.
Shifting to the current standard, compare these two declarations:
05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
05 MY-FIELD-2 PIC +9999.
I always use the first form, but since the invention of de-editing
aren't these declarations equivalent? Isn't it clearer and simpler to
use the latter form? This makes SIGN SEPARATE obsolescent. Or am I
missing some subtle distinction here?
--
I |\ Randall Bart mailto:Bart...@usa.spam.net
L |/
o |\ Bart...@worldnet.att.spam.net Bart...@hotmail.spam.com
v | \ 1-310-542-6013 Please reply without spam
e |\
Y |/ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00
o |\ 33rd term revealed. Is it easy yet?:
u |/ http://members.aol.com/PanicYr00/Sequence.html
William M. Klein
RandallBart wrote in message <6eko19$h...@bgtnsc02.worldnet.att.net>...
Joke - does the Standard (changed or the same) EVER make things "clearer".
(I can say this because I have - and continue to - work on it.)
More seriously, what the change is trying to do is to fix a problem with the
current Standard.
In one place it says that you can have "BLANK WHEN ZERO" with an otherwise
numeric item - and that this makes it numeric-edited.
In another place it says two things about numeric-edited items
A) they must have certain characters 9's and V's are allowed, but S's and
P's are not allowed.
B) To be a numeric-edited item, the Picture must include at least one of
a list characters (such as B, 0, comma, etc)
The first rule means that 99PP and S99 can't be used with BLANK WHEN ZERO
(because numeric-edited items can't have Ps and S's)
The second rule means that 9V9 and 99 can't be used with BLANK WHEN ZERO
because there are no editing symbols (required for BWZ).
****
Now the really INTERESTING thing is that because of this discussion in
comp.lang.cobol, we have discovered that not only has the "fix" not made it
into the draft, half of a General Rule clobbered half of a Syntax Rule - and
what is in the current draft is just "garbage". I'll wait to see how it
gets fixed before telling you if things have gotten better or worse.
P.S. The "Theoretical" difference between
S99 sign is leading separate and
+99
is that even when it is "leading separate" the implementor determines how
the sign is stored (which is probably with a "+" or "-" - but could be
different). This answer is being given withOUT having looked it up, so I
hope I am not misleading you.
Judson McClendon
RandallBart <Bart...@worldnet.att.spam.net> wrote:
> Shifting to the current standard, compare these two declarations:
>
> 05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
> 05 MY-FIELD-2 PIC +9999.
>
> I always use the first form, but since the invention of de-editing
> aren't these declarations equivalent? Isn't it clearer and simpler to
> use the latter form? This makes SIGN SEPARATE obsolescent. Or am I
> missing some subtle distinction here?
It seems to me that the second form would be considered a numeric edited
field, but the first one would not.
RandallBart
Judson McClendon wrote:
>
> RandallBart <Bart...@worldnet.att.spam.net> wrote:
> > 05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
> > 05 MY-FIELD-2 PIC +9999.
> It seems to me that the second form would be considered a numeric edited
> field, but the first one would not.
True, but what functional differences are there? Bill Klein correctly
notes that an implementor could use other than "+" and "-" for sign, but
besides that unlikely scenario, what can you do with one that you can't
with the other? Moving to or from a numeric field must work the same.
What happens when you move a numeric-edited field to a numeric-edited
field? I'm don't have a reference manual at home, so I can't look up
all the combinations.
Renegade
All of a sudden, "Judson McClendon" <judm...@mindspring.com> wrote:
>RandallBart <Bart...@worldnet.att.spam.net> wrote:
>> Shifting to the current standard, compare these two declarations:
>>
>> 05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
>> 05 MY-FIELD-2 PIC +9999.
>>
>> I always use the first form, but since the invention of de-editing
>> aren't these declarations equivalent? Isn't it clearer and simpler to
>> use the latter form? This makes SIGN SEPARATE obsolescent. Or am I
>> missing some subtle distinction here?
>
>It seems to me that the second form would be considered a numeric edited
>field, but the first one would not.
Exactly. The second example is an edit pattern (numeric edited) that
will put a "+" in front of the field if it is positive.
Dave
You may e-mail replies to: renegade at (@) dwx dot (.) com
Cobol Frog (Huib Klink)
RandallBart wrote about PIC S9999 SIGN LEADING SEPARATE:
> True, but what functional differences are there? Bill Klein correctly
> notes that an implementor could use other than "+" and "-" for sign,
8<AFAIK, The NEW Standard says that for positive the '+ ' and for negative the
blank (space, " ") is to be used. Was this direction also in The CURRENT
Standard?
> I'm don't have a reference manual at home, so I can't look up
> all the combinations.
My problem too.
Cobol Frog
William M. Klein
RandallBart wrote in message <6encv6$e...@bgtnsc02.worldnet.att.net>...
>Judson McClendon wrote:
>>
>> RandallBart <Bart...@worldnet.att.spam.net> wrote:
>
>> > 05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
>> > 05 MY-FIELD-2 PIC +9999.
>
>> It seems to me that the second form would be considered a numeric edited
>> field, but the first one would not.
>
>True, but what functional differences are there>
>-- much snippage <
>
>I |\ Randall Bart mailto:Bart...@usa.spam.net
>L |/
>o |\ Bart...@worldnet.att.spam.net Bart...@hotmail.spam.com
>v | \ 1-310-542-6013 Please reply without spam
>e |\
>Y |/ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00
>o |\ 33rd term revealed. Is it easy yet?:
>u |/ http://members.aol.com/PanicYr00/Sequence.html
At least one functional difference is in arithmetic statements. Although
you can use a numeric-edited item as the RECEIVING item in an arithmetic
statement, I do NOT think it can be used in the "sending" type fields.
Thus,
Add Num1 to Num2 Giving Num-Edited
is valid, but
Add Num1 to Num-Edited Giving Num2
is not valid. You could (I think) change the 2nd one to
Add Num1 to Function NumVal (Num-Edited (1:)) Giving Num2
but I would hardly consider that better than just using the "S" in the
original PICTURE clause.
Don Nelson
Cobol Frog (Huib Klink) wrote:
>
> RandallBart wrote about PIC S9999 SIGN LEADING SEPARATE:
>
> > True, but what functional differences are there? Bill Klein correctly
> > notes that an implementor could use other than "+" and "-" for sign,
>
> 8<AFAIK, The NEW Standard says that for positive the '+ ' and for negative the
> blank (space, " ") is to be used. Was this direction also in The CURRENT
> Standard?
The 85 standard and the 74 standard (it wasn't in the 68 standard) all
said only a + or - (standard data format) can be used. It is not at all
implementor defined.
> > I'm don't have a reference manual at home, so I can't look up
> > all the combinations.
>
> My problem too.
I have all those standards and did look it up.
Don Nelson
RandallBart wrote:
>
> Judson McClendon wrote:
> >
> > RandallBart <Bart...@worldnet.att.spam.net> wrote:
>
> > > 05 MY-FIELD-1 PIC S9999 SIGN LEADING SEPARATE.
> > > 05 MY-FIELD-2 PIC +9999.
>
> > It seems to me that the second form would be considered a numeric edited
> > field, but the first one would not.
>
> notes that an implementor could use other than "+" and "-" for sign,
Actually, he incorrectly said this. The only allowable signs are the +
and -. SIGN SEPARATE is designed specifically for data portability.
> but
> besides that unlikely scenario, what can you do with one that you can't
> with the other?
You can't use the edited item in any arithmetic statement. You can use
the numeric one. There are lots of other things as well. Compaisons
are even more interesting.
> Moving to or from a numeric field must work the same.
A numeric one does. A numeric-edited one differs.
> What happens when you move a numeric-edited field to a numeric-edited
> field?
In the COBOL 85 standard you get de-editing and then re-editing. Only
with a MOVE statement, however.
> I'm don't have a reference manual at home, so I can't look up
> all the combinations.
Check it out sometime.