Home > Archive > Cobol > March 2007 > Trying to use STRING
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Trying to use STRING
|
|
|
| As an experienced COBOL programmer I am a bit embarrassed to ask this
question, but as I have never had to do something like this before I
am struggling. I need to create a CSV file. I am using STRING
statement to do this. My problem is that I am getting trailing spaces
left on my text fields and I cannot figure how to fix it. I'm sure
somebody has done this before and will show me the error of my ways.
77 WS-NAME PIC X(30).
77 WS-ADD1 PIC X(30).
77 WS-BALANCE PIC ZZZZZ9.99.
STRING QUOTE WS-NAME QUOTE ","
QUOTE WS-ADD1 QUOTE ","
WS-BALANCE ","
Gives me:
"BOB SMITH ","10 THE HIGH
STREET ", 123.45
But I want
"BOB SMITH","10 THE HIGH STREET", 123.45
or even (just out of interest really as this is not giving me a
problem)
"BOB SMITH","10 THE HIGH STREET",123.45
| |
| Roger While 2007-03-14, 7:55 am |
|
"razor" <iruddock@blueyonder.co.uk> schrieb im Newsbeitrag
news:1173868267.836567.325980@l77g2000hsb.googlegroups.com...
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
>
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
>
If you have the FUNCTION TRIM, like OpenCOBOL has :-),
then you can do -
IDENTIFICATION DIVISION.
PROGRAM-ID. STRINGT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 WS-NAME PIC X(20) value "Bob Smith".
77 WS-ADD1 PIC X(20) value "10 The High Street".
77 WS-BALANCE PIC ZZZZZ9.99.
01 FLOC3 PIC X(70).
PROCEDURE DIVISION.
move 123.45 to ws-balance.
STRING QUOTE delimited size
FUNCTION TRIM (WS-NAME, TRAILING) delimited size
QUOTE delimited size
"," delimited size
QUOTE delimited size
FUNCTION TRIM (WS-ADD1, TRAILING) delimited size
QUOTE delimited size
"," delimited size
FUNCTION TRIM (WS-BALANCE, LEADING) delimited size
"," delimited size
into floc3.
display floc3.
STOP RUN.
Note the "delimited" is only there for completeness and is not required.
Test -
$ cobc -x stringt.cob
$ ./stringt
"Bob Smith","10 The High Street",123.45,
| |
|
| In article <1173868267.836567.325980@l77g2000hsb.googlegroups.com>,
razor <iruddock@blueyonder.co.uk> wrote:
>As an experienced COBOL programmer I am a bit embarrassed to ask this
>question, but as I have never had to do something like this before I
>am struggling.
Not to worry, o'ermuch... we *all* were virgins in one manner or another,
once.
[snip]
>77 WS-NAME PIC X(30).
>77 WS-ADD1 PIC X(30).
>77 WS-BALANCE PIC ZZZZZ9.99.
Hmmmm... all caps, 77s to save on memory alignment, everything prefixed
with WS-... my guess is IBM mainframe or compatible as the original
platform.
>
>STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
>Gives me:
>
>"BOB SMITH ","10 THE HIGH
>STREET ", 123.45
>
>But I want
>
>"BOB SMITH","10 THE HIGH STREET", 123.45
>
>or even (just out of interest really as this is not giving me a
>problem)
>
>"BOB SMITH","10 THE HIGH STREET",123.45
Oh look, embedded spaces... and just to make life easier I'll assume that
there's an unpredictable number of embedded spaces, so that STRING WS-NAME
DELIMITED BY ' ' (etc.) will make someone unhappy just because the name is
'BOB(space)(space)SMITH'. Just for amateurish starters... how about
something like:
PERFORM VARYING WS-NAME-SUB FROM LENGTH OF WS-NAME
BY -1 UNTIL WS-NAME(WS-NAME-SUB:1) NOT = ' '
OR WS-NAME-SUB = 0
CONTINUE
END-PERFORM
.... so that if WS-NAME contains something simple, like:
'JIM BOB SMITH IV '
.... then WS-NAME-SUB should tick backwards from 30 to (squint point point)
17. Do likewise with WS-ADD1 and see if
STRING QUOTE, WS-NAME(1:WS-NAME-SUB),
QUOTE, ',',
QUOTE, WS-ADD1(1:WS-ADD1-SUB),
QUOTE, ','.
WS-BALANCE
DELIMITED BY SIZE
INTO WS-CSV-REC
.... will even compile, let alone give you something potentially useful.
(Truncating leading spaces on WS-BALANCE is left as an exercise to the
reader.)
DD
| |
| Roger While 2007-03-14, 7:55 am |
|
<docdwarf@panix.com> schrieb im Newsbeitrag
news:et8p4m$mko$1@reader2.panix.com...
> In article <1173868267.836567.325980@l77g2000hsb.googlegroups.com>,
> razor <iruddock@blueyonder.co.uk> wrote:
>
> Not to worry, o'ermuch... we *all* were virgins in one manner or another,
> once.
>
> [snip]
>
>
> Hmmmm... all caps, 77s to save on memory alignment, everything prefixed
> with WS-... my guess is IBM mainframe or compatible as the original
> platform.
>
>
> Oh look, embedded spaces... and just to make life easier I'll assume that
> there's an unpredictable number of embedded spaces, so that STRING WS-NAME
> DELIMITED BY ' ' (etc.) will make someone unhappy just because the name is
> 'BOB(space)(space)SMITH'. Just for amateurish starters... how about
> something like:
>
> PERFORM VARYING WS-NAME-SUB FROM LENGTH OF WS-NAME
> BY -1 UNTIL WS-NAME(WS-NAME-SUB:1) NOT = ' '
> OR WS-NAME-SUB = 0
> CONTINUE
> END-PERFORM
>
Two slaps on the wrist :-)
1) LENGTH OF isn't standard or ? (Use FUNCTION LENGTH)
2) Na-na, Using the subscript before checking for 0 ?
| |
| HeyBub 2007-03-14, 7:55 am |
| razor wrote:
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
>
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45
>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
STRING QUOTE DELIMITED SIZE
WSNAME DELIMITED "bb"
QUOTE "," DELIMITED SIZE
WS-ADD1 DELIMITED "bb"
QUOTE "," DELIMITED SIZE
WS-BALANCE DELIMITED SIZE
where 'bb' is two consecutive spaces.
This of course assumes you don't have two consecutive imbedded spaces in the
name or address - if you do, you should fix that first.
| |
| Pete Dashwood 2007-03-14, 6:55 pm |
|
"razor" <iruddock@blueyonder.co.uk> wrote in message
news:1173868267.836567.325980@l77g2000hsb.googlegroups.com...
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
77 ws-balance-x redefines ws-balance pic x(9).
77 my-tally pic s9(4) comp.
>
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45
>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
>
The following is pretty basic COBOL and does not use intrinsic functions. A
better solution is possible if you DO use intrinsic functions, especially if
you have Fujitsu COBOL which includes the STORED-CHAR-LENGTH function.
For your FIRST request...:
move spaces to output-string
string
quote
ws-name
delimited by " " *> this is TWO spaces... if the data has
*> TWO spaces between words (by
*> accident or design) it will be
truncated.
*> Consider using THREE spaces...
quote
","
delimited by size
ws-add1
delimited by " " *> see comments above...
quote
","
delimited by size
ws-balance
delimited by size
into output-string
end-string
For your SECOND request...
inspect ws-balance-x
tallying my-tally
for leading spaces
compute L = 9 - my-tally *> ugly hard-coded length
*> should be intrinsic LENGTH
move spaces to output-string
string
quote
ws-name
delimited by " " *> this is TWO spaces... if the data has
*> TWO spaces between words (by
*> accident or design) it will be
truncated.
*> Consider using THREE spaces...
quote
","
delimited by size
ws-add1
delimited by " " *> see comments above...
quote
","
delimited by size
ws-balance (my-tally + 1: Len)
delimited by size
into output-string
end-string
Hope this helps,
Pete.
| |
|
| In article <et8qpo$pqp$03$1@news.t-online.com>,
Roger While <simrw@sim-basis.de> wrote:
>
><docdwarf@panix.com> schrieb im Newsbeitrag
>news:et8p4m$mko$1@reader2.panix.com...
[snip]
>
>Two slaps on the wrist :-)
>1) LENGTH OF isn't standard or ? (Use FUNCTION LENGTH)
>2) Na-na, Using the subscript before checking for 0 ?
An 'amateurish starter' generates only two slaps? I guess amateurs have
changed since I last dealt with them.
DD
| |
|
| Sorry, should have added I am using MF Netexpress 3.1.
Why do these request for help result in people trying to 'outcode'
each other? Thanks for everybody's efforts. The point of my post was
to see if I was missing something on the STRING statement. I had been
playing with the DELIMITED clause thinking that the answer lay there.
Apparently not.
Thanks Roger but I don't have the TRIM function in MF (I believe).
I don't like having to rely on two (or more) spaces as this is a fudge
and will come back to haunt a future COBOL trainee given his first
debugging task.
I had already thought about reading backwards through each string and
using 'Reference modification' to effectively trim each field.
Thanks DD for your help. Sorry, but your assumptions about 77's was
incorrect. I have never used mainframe so never had to worry about
word alignment and now just don't care whether I use 77 or 01 levels.
Yes, I'm 'out there crazy' aren't I.
So my solution will have to be as I had originally thought, but very
inelegant.
77 WS-NAME PIC X(30).
77 WS-ADD1 PIC X(30).
77 WS-BALANCE PIC ZZZZZ9.99.
77 WS-STRING PIC X(60).
77 WS-STRING-LENGTH PIC 99.
77 WS-NAME-LENGTH PIC 99.
77 WS-ADD1-LENGTH PIC 99.
MOVE WS-NAME TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
LENGTH TO WS-NAME-LENGTH.
MOVE WS-ADD1 TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
LENGTH TO WS-ADD1-LENGTH.
(Yes, I really will make it look like this. When I have 12 in a row it
will look neat)
STRING QUOTE WS-NAME(1:WS-NAME-LENGTH) QUOTE ","
QUOTE WS-ADD1(1:WS-ADD1-LENGTH) QUOTE ","
WS-BALANCE ","
GET-LENGTH-OF-STRING SECTION. (NO comments invited.....)
PERFORM VARYING WS-SUB FROM 60 BY -1 UNTIL WS-SUB = 0
IF WS-STRING(WS-SUB:1) NOT = " "
EXIT SECTION.
If i really needed to trim off the spaces from the beginning of the WS-
BALANCE field I would have to do something similar to both mine and
Pete D's suggestion, but I can't be bothered.
Thanks to all, as its my first request for help, standby for
more....:-)
| |
|
| In article <1173881236.224187.243780@o5g2000hsb.googlegroups.com>,
razor <iruddock@blueyonder.co.uk> wrote:
>Sorry, should have added I am using MF Netexpress 3.1.
>
>Why do these request for help result in people trying to 'outcode'
>each other?
I'm not sure if that is what is happening, Mr Ruddock, or whether it is
'this is what comes to my mind'; you asked for help with code and coders
offered help... and code.
[snip]
>I don't like having to rely on two (or more) spaces as this is a fudge
>and will come back to haunt a future COBOL trainee given his first
>debugging task.
It is best, I've found, to make as few assumptions about data as possible;
'it will be terminated by two spaces and never, *ever*, contain two
embedded spaces' is more reliant on purity than I like to be. As my first
programming instructor asked the class:
'What is the definition of a 'computer user'?
(pause for responses, each met with a curt 'No')
'A 'computer user' is someone who, when prompted to supply a 'Y' or 'N'
response, will key in the numeral '8'. Write *all* of your online
applications with this in mind and your users will love you.'
Life may not be that simple, no... but I've found it a good rule to
remember.
>
>I had already thought about reading backwards through each string and
>using 'Reference modification' to effectively trim each field.
Great minds running in similar and small circles, perhaps.
>
>Thanks DD for your help. Sorry, but your assumptions about 77's was
>incorrect. I have never used mainframe so never had to worry about
>word alignment and now just don't care whether I use 77 or 01 levels.
>Yes, I'm 'out there crazy' aren't I.
Not in the least... I heard hoofbeats and I concluded 'horses'; this w
it was zebras... I'll survive the stampede, somehow.
>
>So my solution will have to be as I had originally thought, but very
>inelegant.
>
>77 WS-NAME PIC X(30).
>77 WS-ADD1 PIC X(30).
>77 WS-BALANCE PIC ZZZZZ9.99.
>77 WS-STRING PIC X(60).
>77 WS-STRING-LENGTH PIC 99.
>77 WS-NAME-LENGTH PIC 99.
>77 WS-ADD1-LENGTH PIC 99.
>
>
>MOVE WS-NAME TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
>LENGTH TO WS-NAME-LENGTH.
Once it is cleaned up I'd say the mechanism (use of common area and code)
is one I've seen before; as a matter of style I'd prefer doing it all 'in
place' as my given example indicated.
If you have access to someone who can be used as the 'future COBOL
trainee' you mention being concerned about - a more common use, in my
experience, is 'a two-year programmer' - you might want to present both
styles and see what the response is.
[snip]
>Thanks to all, as its my first request for help, standby for
>more....:-)
For a first request it seemed remarkably well-formed, with examples of
data, what you want and (most importantly, to some) what you've tried
already.
DD
| |
| Howard Brazee 2007-03-14, 6:55 pm |
| On 14 Mar 2007 03:31:07 -0700, "razor" <iruddock@blueyonder.co.uk>
wrote:
>STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
>Gives me:
>
>"BOB SMITH ","10 THE HIGH
>STREET ", 123.45
While you can delimit by " ", I find that this is a bit too much data
dependent. I prefer using reference modification when I do this.
| |
| Howard Brazee 2007-03-14, 6:55 pm |
| On Wed, 14 Mar 2007 08:53:08 -0600, Howard Brazee <howard@brazee.net>
wrote:
>
>While you can delimit by " ", I find that this is a bit too much data
>dependent. I prefer using reference modification when I do this.
I have used a routine that waits until my record has been built -
which works from the end of the record looking for end-delimiters
preceded by spaces and bumps everything up one. I'm not sure how
efficient this is compared to compressing each delimited field as it
is created. But it can make programming maintenance easier.
| |
|
| In article <ou5gv2tts481ncmm84nrnvjq624r8gt4g8@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Wed, 14 Mar 2007 08:53:08 -0600, Howard Brazee <howard@brazee.net>
>wrote:
>
>
>I have used a routine that waits until my record has been built -
>which works from the end of the record looking for end-delimiters
>preceded by spaces and bumps everything up one.
This 'work from the bottom up to the top' was a technique I was taught lo,
those many years ago, for CICS screen error-checking; it allows one to
point out all errors (intensify video/highlight) while positioning the
cursor at the first one (reading left-to-right, top-to-bottom) to be
corrected.
DD
| |
| Frank Swarbrick 2007-03-14, 6:55 pm |
| On 3/14/2007 at 8:07 AM, in message
<1173881236.224187.243780@o5g2000hsb.googlegroups.com>,
razor<iruddock@blueyonder.co.uk> wrote:
> Sorry, should have added I am using MF Netexpress 3.1.
>
> Why do these request for help result in people trying to 'outcode'
> each other? Thanks for everybody's efforts. The point of my post was
> to see if I was missing something on the STRING statement. I had been
> playing with the DELIMITED clause thinking that the answer lay there.
> Apparently not.
>
> Thanks Roger but I don't have the TRIM function in MF (I believe).
>
> I don't like having to rely on two (or more) spaces as this is a fudge
> and will come back to haunt a future COBOL trainee given his first
> debugging task.
>
> I had already thought about reading backwards through each string and
> using 'Reference modification' to effectively trim each field.
>
> Thanks DD for your help. Sorry, but your assumptions about 77's was
> incorrect. I have never used mainframe so never had to worry about
> word alignment and now just don't care whether I use 77 or 01 levels.
> Yes, I'm 'out there crazy' aren't I.
>
> So my solution will have to be as I had originally thought, but very
> inelegant.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
> 77 WS-STRING PIC X(60).
> 77 WS-STRING-LENGTH PIC 99.
> 77 WS-NAME-LENGTH PIC 99.
> 77 WS-ADD1-LENGTH PIC 99.
>
>
> MOVE WS-NAME TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-NAME-LENGTH.
> MOVE WS-ADD1 TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-ADD1-LENGTH.
>
> (Yes, I really will make it look like this. When I have 12 in a row it
> will look neat)
>
> STRING QUOTE WS-NAME(1:WS-NAME-LENGTH) QUOTE ","
> QUOTE WS-ADD1(1:WS-ADD1-LENGTH) QUOTE ","
> WS-BALANCE ","
>
>
> GET-LENGTH-OF-STRING SECTION. (NO comments invited.....)
> PERFORM VARYING WS-SUB FROM 60 BY -1 UNTIL WS-SUB = 0
> IF WS-STRING(WS-SUB:1) NOT = " "
> EXIT SECTION.
>
>
> If i really needed to trim off the spaces from the beginning of the WS-
> BALANCE field I would have to do something similar to both mine and
> Pete D's suggestion, but I can't be bothered.
>
> Thanks to all, as its my first request for help, standby for
> more....:-)
It is unfortunate, I think, that the COBOL 85 standard did not offer an
obvious way of doing this. Something, perhaps, like:
STRING QUOTE WS-NAME QUOTE ","
QUOTE WS-ADD1 QUOTE ","
WS-BALANCE ","
DELIMITED BY TRAILING SPACES
INTO MY-RECORD
Seems to me like such an obvious thing to want. I bet you'll agree. And
given the number of times this question comes up it also appears that people
assume that a simple STRING statement should be able to be utilized. Alas,
such is not the case.
I do like Roger's use of the TRIM function. Too bad that's not available in
most COBOL compilers. In fact, I don't think it's even part of the COBOL
2002 standard. It's part of the NEXT proposed standard, right?
Ah well...
Frank
| |
| James J. Gavan 2007-03-14, 6:55 pm |
| razor wrote:
> Sorry, should have added I am using MF Netexpress 3.1.
>
> Why do these request for help result in people trying to 'outcode'
> each other? Thanks for everybody's efforts. The point of my post was
> to see if I was missing something on the STRING statement. I had been
> playing with the DELIMITED clause thinking that the answer lay there.
> Apparently not.
>
> Thanks Roger but I don't have the TRIM function in MF (I believe).
>
> I don't like having to rely on two (or more) spaces as this is a fudge
> and will come back to haunt a future COBOL trainee given his first
> debugging task.
>
> I had already thought about reading backwards through each string and
> using 'Reference modification' to effectively trim each field.
>
> Thanks DD for your help. Sorry, but your assumptions about 77's was
> incorrect. I have never used mainframe so never had to worry about
> word alignment and now just don't care whether I use 77 or 01 levels.
> Yes, I'm 'out there crazy' aren't I.
>
> So my solution will have to be as I had originally thought, but very
> inelegant.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
> 77 WS-STRING PIC X(60).
> 77 WS-STRING-LENGTH PIC 99.
> 77 WS-NAME-LENGTH PIC 99.
> 77 WS-ADD1-LENGTH PIC 99.
>
>
> MOVE WS-NAME TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-NAME-LENGTH.
> MOVE WS-ADD1 TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-ADD1-LENGTH.
>
> (Yes, I really will make it look like this. When I have 12 in a row it
> will look neat)
>
> STRING QUOTE WS-NAME(1:WS-NAME-LENGTH) QUOTE ","
> QUOTE WS-ADD1(1:WS-ADD1-LENGTH) QUOTE ","
> WS-BALANCE ","
>
>
> GET-LENGTH-OF-STRING SECTION. (NO comments invited.....)
> PERFORM VARYING WS-SUB FROM 60 BY -1 UNTIL WS-SUB = 0
> IF WS-STRING(WS-SUB:1) NOT = " "
> EXIT SECTION.
>
>
> If i really needed to trim off the spaces from the beginning of the WS-
> BALANCE field I would have to do something similar to both mine and
> Pete D's suggestion, but I can't be bothered.
>
> Thanks to all, as its my first request for help, standby for
> more....:-)
>
Want to get real brave in N/E V3.1 - then make OO work for you :-). I
have previously posted a version here and in the M/F Forum - but I'll
e-mail you direct the latest version which you could adapt.
The advantage is that you can string any number of fields, (dropping
intervening spaces), regardless of different input record sizes, or a
varying number of fields per record-type and you don't have to worry
about counters to figure out where you are.
Checked the on-line - Nope. Although listed, TRIM is used only with CGI
and dynamic queries.
Jimmy
| |
| Richard 2007-03-14, 6:55 pm |
| On Mar 14, 11:31 pm, "razor" <irudd...@blueyonder.co.uk> wrote:
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45
>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
You may also want to worry about a text field that includes a quote or
two. The quotes around each text field is to avoid any problems with
included commas, but each included quote needs to be doubled.
| |
| Howard Brazee 2007-03-14, 6:55 pm |
| On 14 Mar 2007 11:08:08 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>You may also want to worry about a text field that includes a quote or
>two. The quotes around each text field is to avoid any problems with
>included commas, but each included quote needs to be doubled.
To be safer, I wouldn't use any delimiters that could be data whenever
you have a choice. That includes commas. Up front analysis of
the data and checking of the data during processing is warranted.
| |
| HeyBub 2007-03-14, 6:55 pm |
| razor wrote:
> Sorry, should have added I am using MF Netexpress 3.1.
>
> Why do these request for help result in people trying to 'outcode'
> each other? Thanks for everybody's efforts. The point of my post was
> to see if I was missing something on the STRING statement. I had been
> playing with the DELIMITED clause thinking that the answer lay there.
> Apparently not.
The answer IS in the use of STRING - or at least one answer.
>
> Thanks Roger but I don't have the TRIM function in MF (I believe).
>
> I don't like having to rely on two (or more) spaces as this is a fudge
> and will come back to haunt a future COBOL trainee given his first
> debugging task.
Not if you guarantee there are no double spaces. Two or more consecutive
imbedded spaces is a mistake, a typo, an error. Multiple spaces should have
been caught (and corrected) by the original data-entry validation code.
For example, we have a left-justify routine that converts multiple spaces to
a single space as part of its justification process. This routine is invoked
for every text input field.
>
> I had already thought about reading backwards through each string and
> using 'Reference modification' to effectively trim each field.
>
> Thanks DD for your help. Sorry, but your assumptions about 77's was
> incorrect. I have never used mainframe so never had to worry about
> word alignment and now just don't care whether I use 77 or 01 levels.
> Yes, I'm 'out there crazy' aren't I.
>
> So my solution will have to be as I had originally thought, but very
> inelegant.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
> 77 WS-STRING PIC X(60).
> 77 WS-STRING-LENGTH PIC 99.
> 77 WS-NAME-LENGTH PIC 99.
> 77 WS-ADD1-LENGTH PIC 99.
>
>
> MOVE WS-NAME TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-NAME-LENGTH.
> MOVE WS-ADD1 TO WS-STRING PERFORM GET-LENGTH-OF-STRING MOVE WS-STRING-
> LENGTH TO WS-ADD1-LENGTH.
>
> (Yes, I really will make it look like this. When I have 12 in a row it
> will look neat)
>
> STRING QUOTE WS-NAME(1:WS-NAME-LENGTH) QUOTE ","
> QUOTE WS-ADD1(1:WS-ADD1-LENGTH) QUOTE ","
> WS-BALANCE ","
>
>
> GET-LENGTH-OF-STRING SECTION. (NO comments invited.....)
> PERFORM VARYING WS-SUB FROM 60 BY -1 UNTIL WS-SUB = 0
> IF WS-STRING(WS-SUB:1) NOT = " "
> EXIT SECTION.
>
>
> If i really needed to trim off the spaces from the beginning of the
> WS- BALANCE field I would have to do something similar to both mine
> and Pete D's suggestion, but I can't be bothered.
>
> Thanks to all, as its my first request for help, standby for
> more....:-)
| |
| Bob Iles 2007-03-14, 6:55 pm |
| razor wrote:
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
>
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45
>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
>
Try the inspect statement to give you a string
that can be delimited by spaces:
inspect ws-name replacing all " " by "~" before " ".
inspect ws-addr1 replacing all " " by "~" before " ".
move spaces to output-line.
string quote ws-name quote ","
quote ws-addr1 quote ","
output-balance delimited by spaces
into output-line
inspect output-line replacing all "~" by " ".
to get a left justified balance you would have to move
your working amount (after formatting) into redefined
field depending upon how large the original field is.
(if someone can show me a better way to left justify
this value please correct me)
example:
01 output-balance pic x(10).
01 WS-BALANCE PIC ZZZZZ9.99.
01 filler redefines ws-balance.
03 filler pic x(1).
03 ws-balance2.
05 filler pic x(1).
05 ws-balance3.
07 filler pic x(1).
07 ws-balance3.
09 filler pic x(1).
09 ws-balance4.
11 filler pic x(1).
11 ws-balance5 pic x(4).
move your-amount to ws-balance.
if your-amount > 99999.99
move ws-balance to output-balance
else
if your-amount > 9999.99
move ws-balance2 to output-balance
else
if your-amount > 999.99
move ws-balance3 to output-balance
else
if your-amount > 99.99
move ws-balance4 to output-balance
else
move ws-balance5 to output-balance.
I know this is ugly but it works. If the "~" causes
trouble, replace it with some H"ff" or something else.
bob
| |
| Richard 2007-03-14, 6:55 pm |
| On Mar 15, 8:24 am, Bob Iles <b...@mikal.com> wrote:
> razor wrote:
>
>
>
>
>
>
>
>
>
> Try the inspect statement to give you a string
> that can be delimited by spaces:
>
> inspect ws-name replacing all " " by "~" before " ".
> inspect ws-addr1 replacing all " " by "~" before " ".
>
> move spaces to output-line.
>
> string quote ws-name quote ","
> quote ws-addr1 quote ","
> output-balance delimited by spaces
> into output-line
>
> inspect output-line replacing all "~" by " ".
I would prefer to process from the end change spaces to low-values
then use a delimiter of low-values. You could even use function
reverse and inspect replacing.
> to get a left justified balance you would have to move
> your working amount (after formatting) into redefined
> field depending upon how large the original field is.
>
> (if someone can show me a better way to left justify
> this value please correct me)
Use reference notation. Inspect tallying all leading spaces and use
that as an offet.
> example:
>
> 01 output-balance pic x(10).
> 01 WS-BALANCE PIC ZZZZZ9.99.
> 01 filler redefines ws-balance.
> 03 filler pic x(1).
> 03 ws-balance2.
> 05 filler pic x(1).
> 05 ws-balance3.
> 07 filler pic x(1).
> 07 ws-balance3.
> 09 filler pic x(1).
> 09 ws-balance4.
> 11 filler pic x(1).
> 11 ws-balance5 pic x(4).
>
> move your-amount to ws-balance.
> if your-amount > 99999.99
> move ws-balance to output-balance
> else
> if your-amount > 9999.99
> move ws-balance2 to output-balance
> else
> if your-amount > 999.99
> move ws-balance3 to output-balance
> else
> if your-amount > 99.99
> move ws-balance4 to output-balance
> else
> move ws-balance5 to output-balance.
>
> I know this is ugly but it works. If the "~" causes
> trouble, replace it with some H"ff" or something else.
OTOH I have templating routines that will output CSV or HTML or XML or
whatever the template specifies.
| |
|
| I've always wanted a "DELIMITED BY TRAILING SPACES" clause for this purpose
(and several others).
Over the years, I've had to handle concatenating strings and eliminating the
trailing spaces so many times - doing it with one simple STRING would have
saved so much time. Of course, a TRIM() function would also suffice.
(Likewise, although not as generic, I'd like to see something like a
"DELIMITED BY COMMA-QUOTED" for UNSTRING, which would handle parsing a
comma-delimited set of values, including dealing with commas within quotes
and removing the quotes from the destination values.)
"razor" <iruddock@blueyonder.co.uk> wrote in message
news:1173868267.836567.325980@l77g2000hsb.googlegroups.com...
> As an experienced COBOL programmer I am a bit embarrassed to ask this
> question, but as I have never had to do something like this before I
> am struggling. I need to create a CSV file. I am using STRING
> statement to do this. My problem is that I am getting trailing spaces
> left on my text fields and I cannot figure how to fix it. I'm sure
> somebody has done this before and will show me the error of my ways.
>
> 77 WS-NAME PIC X(30).
> 77 WS-ADD1 PIC X(30).
> 77 WS-BALANCE PIC ZZZZZ9.99.
>
>
>
> STRING QUOTE WS-NAME QUOTE ","
> QUOTE WS-ADD1 QUOTE ","
> WS-BALANCE ","
>
> Gives me:
>
> "BOB SMITH ","10 THE HIGH
> STREET ", 123.45
>
> But I want
>
> "BOB SMITH","10 THE HIGH STREET", 123.45
>
> or even (just out of interest really as this is not giving me a
> problem)
>
> "BOB SMITH","10 THE HIGH STREET",123.45
>
| |
| Howard Brazee 2007-03-15, 6:55 pm |
| On Wed, 14 Mar 2007 23:02:40 -0400, "JJ" <jj@nospam.com> wrote:
>I've always wanted a "DELIMITED BY TRAILING SPACES" clause for this purpose
>(and several others).
When CoBOL was first developed, a field was a field was a field.
But now there is a need to communicate with a streaming output and
maybe re-thinking a bit at a time is not the optimal way. Enhancing
the old way of doing this a bit won't suffice.
| |
|
| On Mar 14, 7:24 pm, Bob Iles <b...@mikal.com> wrote:
> razor wrote:
>
>
>
>
>
>
>
>
>
> Try the inspect statement to give you a string
> that can be delimited by spaces:
>
> inspect ws-name replacing all " " by "~" before " ".
> inspect ws-addr1 replacing all " " by "~" before " ".
>
> move spaces to output-line.
>
> string quote ws-name quote ","
> quote ws-addr1 quote ","
> output-balance delimited by spaces
> into output-line
>
> inspect output-line replacing all "~" by " ".
>
> to get a left justified balance you would have to move
> your working amount (after formatting) into redefined
> field depending upon how large the original field is.
>
> (if someone can show me a better way to left justify
> this value please correct me)
>
> example:
>
> 01 output-balance pic x(10).
> 01 WS-BALANCE PIC ZZZZZ9.99.
> 01 filler redefines ws-balance.
> 03 filler pic x(1).
> 03 ws-balance2.
> 05 filler pic x(1).
> 05 ws-balance3.
> 07 filler pic x(1).
> 07 ws-balance3.
> 09 filler pic x(1).
> 09 ws-balance4.
> 11 filler pic x(1).
> 11 ws-balance5 pic x(4).
>
> move your-amount to ws-balance.
> if your-amount > 99999.99
> move ws-balance to output-balance
> else
> if your-amount > 9999.99
> move ws-balance2 to output-balance
> else
> if your-amount > 999.99
> move ws-balance3 to output-balance
> else
> if your-amount > 99.99
> move ws-balance4 to output-balance
> else
> move ws-balance5 to output-balance.
>
> I know this is ugly but it works. If the "~" causes
> trouble, replace it with some H"ff" or something else.
>
> bob
Hi Bob
I would have done it like this.
01 ws-balanceX.
03 WS-BALANCE PIC ZZZZZZZ9.99.
01 WS-BALANCE-START PIC 99.
PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
IF WS-BALANCEX(WS-SUB:1) NOT = " "
ADD 1 WS-SUB GIVING WS-BALANCE-START
EXIT PERFORM
END-IF
END-PERFORM.
Then in my string statement I can use
STRING .... "," WS-BALANCEX(WS-BALANCE-START:) "," ........
But I dont need to do it anyway because the application processing the
CSV file is handling leading spaces in front of a balance field. The
customer told me that trailing spaces on the text fields were not
behaving properly and thats why I had to 'trim' them. I'm not sure
they were right, but the customer is ALWAYS correct.
Thanks
| |
|
| On Mar 15, 2:44 pm, "razor" <irudd...@blueyonder.co.uk> wrote:
> On Mar 14, 7:24 pm, Bob Iles <b...@mikal.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Bob
>
> I would have done it like this.
>
> 01 ws-balanceX.
> 03 WS-BALANCE PIC ZZZZZZZ9.99.
> 01 WS-BALANCE-START PIC 99.
>
> PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
> IF WS-BALANCEX(WS-SUB:1) NOT = " "
> ADD 1 WS-SUB GIVING WS-BALANCE-START
> EXIT PERFORM
> END-IF
> END-PERFORM.
>
> Then in my string statement I can use
>
> STRING .... "," WS-BALANCEX(WS-BALANCE-START:) "," ........
>
> But I dont need to do it anyway because the application processing the
> CSV file is handling leading spaces in front of a balance field. The
> customer told me that trailing spaces on the text fields were not
> behaving properly and thats why I had to 'trim' them. I'm not sure
> they were right, but the customer is ALWAYS correct.
>
> Thanks
I meant
PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
IF WS-BALANCEX(WS-SUB:1) NOT = " "
MOVE WS-SUB TO WS-BALANCE-START
EXIT PERFORM
END-IF
END-PERFORM.
| |
| Bob Iles 2007-03-15, 6:55 pm |
| razor wrote:
> On Mar 15, 2:44 pm, "razor" <irudd...@blueyonder.co.uk> wrote:
>
>
> I meant
>
> PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
> IF WS-BALANCEX(WS-SUB:1) NOT = " "
> MOVE WS-SUB TO WS-BALANCE-START
> EXIT PERFORM
> END-IF
> END-PERFORM.
>
Thanks,
Just curious though as to what would your cobol do if the WS-SUB becomes 12?
bob.
| |
| Richard 2007-03-15, 6:55 pm |
| On Mar 16, 9:37 am, Bob Iles <b...@mikal.com> wrote:
> razor wrote:
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
> Just curious though as to what would your cobol do if the WS-SUB becomes 12?
First of all it cannot do so. Because WS-Balance is not 'blank when
zero' the 8th thru 11th chacters will be not be spaces (as long as
some value, any value, has been moved there).
Secondly, when WS-Sub is incremented to 12 the test is done and it
will be found that 'WS-SUB > 11' is true and so the code within the
perform is not done, the next line after the end-perform is.
| |
|
| It is a good question though Bob. When you are coding something like
that you do think 'what if', but as Richard says, it CANNOT happen.
So, your 'first' is true richard, but it makes your 'second'
irrelevant, even if it were true.
Thanks
| |
| Pete Dashwood 2007-03-15, 9:55 pm |
|
"razor" <iruddock@blueyonder.co.uk> wrote in message
news:1174001467.553684.54220@y80g2000hsf.googlegroups.com...
> It is a good question though Bob. When you are coding something like
> that you do think 'what if', but as Richard says, it CANNOT happen.
> So, your 'first' is true richard, but it makes your 'second'
> irrelevant, even if it were true.
>
> Thanks
>
Quoting previous post:
> I would have done it like this.
>
> 01 ws-balanceX.
> 03 WS-BALANCE PIC ZZZZZZZ9.99.
> 01 WS-BALANCE-START PIC 99.
>
> PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
> IF WS-BALANCEX(WS-SUB:1) NOT = " "
> ADD 1 WS-SUB GIVING WS-BALANCE-START
> EXIT PERFORM
> END-IF
> END-PERFORM.
>
> Then in my string statement I can use
>
> STRING .... "," WS-BALANCEX(WS-BALANCE-START:) "," ........
>
This is obviously incorrect, and was corrected in a subsequent post...
>I meant
>PERFORM VARYING WS-SUB FROM 1 BY 1 UNTIL WS-SUB > 11
> IF WS-BALANCEX(WS-SUB:1) NOT = " "
> MOVE WS-SUB TO WS-BALANCE-START
> EXIT PERFORM
> END-IF
>END-PERFORM.
.... although no change has been made to the original data definitions, so
they are intended to stand.
Two observations:
1. Be careful about what CANNOT happen... Richard correctly qualified his
point by saying "if something is moved to the field". However there is
nothing to stop the group level field (ws-balanceX) being initialized and
over writing WS-BALANCE with spaces.
Although this will cause no immediate harm (the PERFORM loop traps the
subscript going out of range and the STRING will string a space between two
commas where the balance is expected) it could have repercussions on
downstream feeds which may re-construct the balance as spaces from the
received string...
2. To my eye this is an ugly solution. I don't like it for the following
reasons:
1. It mixes refmodding with subscripting but does so implicitly so
it isn't immediately obvious.
2. The condition within the complex perform range is redundant;
simply extend the condition up to the controlling loop...
PERFORM
VARYING WS-SUB
FROM 1
BY 1
UNTIL WS-SUB > 11
OR
WS-BALANCEX (WS-SUB:1) NOT = SPACE
END-PERFORM
(Some compilers will flag this as a warning, saying that there must be
something within the perform range. Add CONTINUE immediately preceding the
END-PERFORM if this happens and it bothers you...).
3. Why would anyone code a complex PERFORM to count the number of
leading spaces on a field when there is a perfectly good
COBOL construct that does exactly that?
(INSPECT ws-balanceX
TALLYING WS-SUB
FOR LEADING SPACES
END-INSPECT)
... and please don't let's have all the old chestnuts about run
time performance; the difference between these two
constructs is marginal on any modern processor. (In fact, INSPECT could be
faster on at least one architecture I can think of...)
4. WS-SUB is misleadingly named as if it was a subscript when it is
actually used as an offset.
Sorry, Razor, nothing personal, it is only COBOL, and it is only my personal
opinion...
Pete.
| |
|
| razor wrote:
> So my solution will have to be as I had originally thought, but very
> inelegant.
>
> 77 WS-STRING PIC X(60).
> 77 WS-STRING-LENGTH PIC 99.
....
>
> GET-LENGTH-OF-STRING SECTION. (NO comments invited.....)
> PERFORM VARYING WS-SUB FROM 60 BY -1 UNTIL WS-SUB = 0
> IF WS-STRING(WS-SUB:1) NOT = " "
> EXIT SECTION.
One comment, performance-wise. In my environment (which is, admittedly,
different from yours), I saw much, much faster performance by using a
table with an index vs. reference modification.
01 WS-STRING PIC X(60).
01 WS-STRING-CHARS REDEFINES WS-STRING.
12 WS-STRING-CHAR OCCURS 60 TIMES
INDEXED BY WS-STRING-IDX
PIC X(01).
01 WS-STRING-LENGTH PIC 99.
....
GET-LENGTH-OF-STRING SECTION.
PERFORM VARYING WS-STRING-IDX FROM 60 BY -1
UNTIL WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
OR WS-STRING-IDX < 1
CONTINUE
END-PERFORM
SET WS-STRING-LENGTH TO WS-STRING-IDX
EXIT SECTION.
Or, for a little bit worse performance but a little more elegance...
01 WS-STRING PIC X(60).
01 WS-STRING-LENGTH PIC 99.
....
GET-LENGTH-OF-STRING SECTION.
MOVE ZERO TO WS-STRING-LENGTH
INSPECT FUNCTION REVERSE (WS-STRING)
TALLYING WS-STRING-LENGTH FOR LEADING SPACE
SUBTRACT 60 FROM WS-STRING-LENGTH
EXIT SECTION.
That last one will actually result in a negative number, but since it's
unsigned, it has the effect of flipping it on the length of the string.
Some comments would be prudent if you're concerned about the guy who's
training being able to understand what was on your mind when you wrote
the code. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Rick Smith 2007-03-16, 3:56 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:55ua5kF26srs0U1@mid.individual.net...
>
> "razor" <iruddock@blueyonder.co.uk> wrote in message
> news:1174001467.553684.54220@y80g2000hsf.googlegroups.com...
>
> Quoting previous post:
>
>
> This is obviously incorrect, and was corrected in a subsequent post...
>
>
>
> ... although no change has been made to the original data definitions, so
> they are intended to stand.
>
> Two observations:
>
> 1. Be careful about what CANNOT happen... Richard correctly qualified his
> point by saying "if something is moved to the field". However there is
> nothing to stop the group level field (ws-balanceX) being initialized and
> over writing WS-BALANCE with spaces.
INITIALIZE WS-BALANCE-X
Actually, if ws-balance-x is initialized, ws-balance will
have seven spaces followed by 0.00. (Well, technically,
pedantically, or unambiguously. Your choice! <g> )
> Although this will cause no immediate harm (the PERFORM loop traps the
> subscript going out of range and the STRING will string a space between
two
> commas where the balance is expected) it could have repercussions on
> downstream feeds which may re-construct the balance as spaces from the
> received string...
>
> 2. To my eye this is an ugly solution. I don't like it for the following
> reasons:
>
> 1. It mixes refmodding with subscripting but does so implicitly so
> it isn't immediately obvious.
> 2. The condition within the complex perform range is redundant;
> simply extend the condition up to the controlling loop...
Steve McConnell, "Code Complete", Microsoft Press, 1993,
page 326, on the subject "When to Use a loop-with-exit Loop",
says, "A loop-with-exit loop is a loop in which the exit condition
appears in the middle of the loop rathe than at the beginning or
at the end. The loop-with-exit lop is available explicity in Ada,
and you can emulate it [in other langauges]. ...
"The loop-with-exit loop is a one-entry, one-exit, structured
control construct, and is the preferred kind of loop control in
Ada programming (Software Productivity Consortium 1989).
It has been shown to be easier to understand than other kinds
of loops. A study of student programmers compared this kind
of loop with those that exited at either the top or bottom
(Soloway, Bonar, and Ehrlich 1983). Students scored 25
percent higher on a test of comprehension when loop-with-exit
loops where used, and the authors of the study concluded that
the loop-with-exit structure more closely models the way people
think about iterative control than other loop structures do.
"The loop-with-exit loop isn't widely used yet. The jury is still
locked in a smoky room arguing about whether it's a good
practice. Until the jury is in, the loop-with-exit is a good
technique to have in your programmer's toolbox--as long as
you use it carefully."
> PERFORM
> VARYING WS-SUB
> FROM 1
> BY 1
> UNTIL WS-SUB > 11
> OR
> WS-BALANCEX (WS-SUB:1) NOT = SPACE
> END-PERFORM
>
> (Some compilers will flag this as a warning, saying that there must be
> something within the perform range. Add CONTINUE immediately preceding the
> END-PERFORM if this happens and it bothers you...).
>
> 3. Why would anyone code a complex PERFORM to count the number of
> leading spaces on a field when there is a perfectly good
> COBOL construct that does exactly that?
> (INSPECT ws-balanceX
> TALLYING WS-SUB
> FOR LEADING SPACES
> END-INSPECT)
> ... and please don't let's have all the old chestnuts about
run
> time performance; the difference between these two
> constructs is marginal on any modern processor. (In fact, INSPECT could be
> faster on at least one architecture I can think of...)
Use of the INSPECT statement actually requires two thoughts;
one for initialization and the other for the inspect itself. This
form attempts to find an answer by doing the opposite of what
is desired. ("I don't want to know how many spaces there are;
I want to know the location of the first non-space character! <g> )
A simple loop requires only one thought; that which is desired.
> 4. WS-SUB is misleadingly named as if it was a subscript when it
is
> actually used as an offset.
>
> Sorry, Razor, nothing personal, it is only COBOL, and it is only my
personal
> opinion...
| |
| Roger While 2007-03-16, 7:56 am |
|
"LX-i" <lxi0007@netscape.net> schrieb im Newsbeitrag
news:JKGdnZJHNtmDl2fYnZ2dnUVZ_rOqnZ2d@co
mcast.com...
> razor wrote:
> ...
>
> One comment, performance-wise. In my environment (which is, admittedly,
> different from yours), I saw much, much faster performance by using a
> table with an index vs. reference modification.
>
> 01 WS-STRING PIC X(60).
> 01 WS-STRING-CHARS REDEFINES WS-STRING.
> 12 WS-STRING-CHAR OCCURS 60 TIMES
> INDEXED BY WS-STRING-IDX
> PIC X(01).
> 01 WS-STRING-LENGTH PIC 99.
> ...
> GET-LENGTH-OF-STRING SECTION.
> PERFORM VARYING WS-STRING-IDX FROM 60 BY -1
> UNTIL WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
> OR WS-STRING-IDX < 1
> CONTINUE
> END-PERFORM
> SET WS-STRING-LENGTH TO WS-STRING-IDX
> EXIT SECTION.
>
Geez, once again using a subscript before testing for zero.
> Or, for a little bit worse performance but a little more elegance...
>
> 01 WS-STRING PIC X(60).
> 01 WS-STRING-LENGTH PIC 99.
> ...
> GET-LENGTH-OF-STRING SECTION.
> MOVE ZERO TO WS-STRING-LENGTH
> INSPECT FUNCTION REVERSE (WS-STRING)
> TALLYING WS-STRING-LENGTH FOR LEADING SPACE
> SUBTRACT 60 FROM WS-STRING-LENGTH
> EXIT SECTION.
>
> That last one will actually result in a negative number, but since it's
> unsigned, it has the effect of flipping it on the length of the string.
> Some comments would be prudent if you're concerned about the guy who's
> training being able to understand what was on your mind when you wrote the
> code. :)
>
>
Or if you use OpenCOBOL -
INSPECT ws-string TALLYING ws-string-length
FOR TRAILING SPACE
:-)
Using the sorely missed (in the standard) TRAILING option of the INSPECT.
| |
|
| Roger While wrote:
> "LX-i" <lxi0007@netscape.net> schrieb im Newsbeitrag
> news:JKGdnZJHNtmDl2fYnZ2dnUVZ_rOqnZ2d@co
mcast.com...
>
> Geez, once again using a subscript before testing for zero.
If it's all spaces, the length will be zero - am I missing something?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Rick Smith 2007-03-16, 6:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:NOidnVcZELCzAGfYnZ2dnUVZ_tninZ2d@co
mcast.com...
> Roger While wrote:
>
> If it's all spaces, the length will be zero - am I missing something?
At some point
UNTIL WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
will become
UNTIL WS-STRING-CHAR ( 0 ) NOT = SPACE
causing an out-of-bounds or range error.
Reversing the conditions prevents that from happening.
| |
| Frank Swarbrick 2007-03-16, 6:55 pm |
| >>> On 3/15/2007 at 11:16 PM, in message
<12vk6ivepdcj338@corp.supernews.com>,
Rick Smith<ricksmith@mfi.net> wrote:
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:55ua5kF26srs0U1@mid.individual.net...
> so
> his
and[color=darkred]
>
> INITIALIZE WS-BALANCE-X
>
> Actually, if ws-balance-x is initialized, ws-balance will
> have seven spaces followed by 0.00. (Well, technically,
> pedantically, or unambiguously. Your choice! <g> )
>
> two
> so
>
> Steve McConnell, "Code Complete", Microsoft Press, 1993,
> page 326, on the subject "When to Use a loop-with-exit Loop",
> says, "A loop-with-exit loop is a loop in which the exit condition
> appears in the middle of the loop rathe than at the beginning or
> at the end. The loop-with-exit lop is available explicity in Ada,
> and you can emulate it [in other langauges]. ...
>
> "The loop-with-exit loop is a one-entry, one-exit, structured
> control construct, and is the preferred kind of loop control in
> Ada programming (Software Productivity Consortium 1989).
> It has been shown to be easier to understand than other kinds
> of loops. A study of student programmers compared this kind
> of loop with those that exited at either the top or bottom
> (Soloway, Bonar, and Ehrlich 1983). Students scored 25
> percent higher on a test of comprehension when loop-with-exit
> loops where used, and the authors of the study concluded that
> the loop-with-exit structure more closely models the way people
> think about iterative control than other loop structures do.
>
> "The loop-with-exit loop isn't widely used yet. The jury is still
> locked in a smoky room arguing about whether it's a good
> practice. Until the jury is in, the loop-with-exit is a good
> technique to have in your programmer's toolbox--as long as
> you use it carefully."
Makes total sense to me.
I've taken the following examples from
http://en.wikibooks.org/wiki/Ada_Pr.../Control#Loops.
------------
While_Loop :
while X <= 5 loop
X := Calculate_Something;
end loop While_Loop;
------------
Until_Loop :
loop
X := Calculate_Something;
exit Until_Loop when X > 5;
end loop Until_Loop;
------------
Exit_Loop :
loop
X := Calculate_Something;
exit Exit_Loop when X > 5;
Do_Something (X);
end loop Exit_Loop;
------------
Caveat: I don't know Ada, other than reading a bit amount it, and knowing
it's somewhat in the Pascal family of languages.
Anyway, I like it. One thing that always bugs my in COBOL is "priming"
reads. For example...
read-next-record
perform until end-of-file
perform process-record
perform read-next-record
end-perform
Although its so common that any COBOL programmer should know what it's
doing, I still don't like it.
Of course you could always do this:
perform until end-of-file
perform read-next-record
if not end-of-file
perform process-record
end-if
end-perform
But then you are checking the EOF condition twice; once to see if you should
do process-record and one to see if you should exit the loop.
Again, yuck!
It looks like in Ada one might do something like this:
Read_Loop :
loop
X := Read_Next_Record(record);
exit Read_Loop when X = EOF;
Do_Something(record);
end loop Read_Loop;
Now *that* I can get into.
In C you might do something like this:
while (read_next_record(record) != EOF) {
do_something(record);
}
I like that just as well, and perhaps even more than the "loop with
condition in the middle". But it does rely on the function in the while
loop returning a result that can be used to check the 'ending' condition.
Since COBOL perform statements don't return a value you can't really utilize
that paradigm. There's always COBOL user-defined functions, but then you
might end up with a lot of little functions instead of paragraphs. This may
be good or not good, but doesn't help if you want to stick with
paragraphs/sections.
Anyway, something like this might be OK:
perform until exit
perform read-next-record
if end-of-file
exit perform
end-if
perform process-record
end-perform
A bit verbose, but OK. Of course it's very, very similar to my second
example above. So much that one would be justified in questioning why we'd
want to add something new to COBOL for it when we can already do pretty much
the same thing.
Going with the Ada method you might have this:
perform until exit
perform read-next-record
exit perform when end-of-file
perform process-record
end-perform
That's pretty nice. Or, if we want to add a new keyword, how about :
loop
perform read-next-record
exit loop when end-of-file
perform process-record
end-loop
No, I have no hope of COBOL having anything like this. Just pondering...
Then, of course, there's our old friend the GOTO:
read-loop.
perform read-next-record
if not end-of-file
perform process-record
goto read-loop
end-if.
While I'd probably never do the above, simply because I've been brainwashed
into avoiding gotos, I don't really see anything wrong with the above.
:-)
Oh, and before someone (Pete) mentions in, yes I do like the .NET foreach
constructs:
C#
foreach (record rec in rec_file) {
rec.do_something();
}
MF NetExpress (COBOL)
perform varying rec through rec_file
rec::"do_something"()
end-perform
That is perhaps the ideal, though it requires OO stuff (iterators and
what-not).
Well, I better get back to real work. :-)
Frank
| |
| Roger While 2007-03-16, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:12vl8krod8ahjcc@corp.supernews.com...
>
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:NOidnVcZELCzAGfYnZ2dnUVZ_tninZ2d@co
mcast.com...
>
> At some point
> UNTIL WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
> will become
> UNTIL WS-STRING-CHAR ( 0 ) NOT = SPACE
> causing an out-of-bounds or range error.
>
> Reversing the conditions prevents that from happening.
>
>
Indeed Rick.
It continually amazes me that people do not understand Cobol rules.
This is not an isolated occurence (as previous posts have shown) and
has occurred in production suites that I have ported.
With some compilers, you will get what you asked for ie:
A reference to an undefined address, which may, or may not
satisfy the criteria.(With no runtime error)
| |
| Roger While 2007-03-16, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
news:eten2e$392$03$1@news.t-online.com...
>
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:12vl8krod8ahjcc@corp.supernews.com...
>
> Indeed Rick.
> It continually amazes me that people do not understand Cobol rules.
> This is not an isolated occurence (as previous posts have shown) and
> has occurred in production suites that I have ported.
> With some compilers, you will get what you asked for ie:
> A reference to an undefined address, which may, or may not
> satisfy the criteria.(With no runtime error)
>
Note, you may NOT assume this for other languages.
(The semantics of OR/AND are interesting)
eg.
In C (array refences are based 0)
if ( myidx < 0 || myarray[myidx] == ' ')
is doomed to failure, while the C compiler may
reorder the test sequence :-)
| |
| Rick Smith 2007-03-16, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:eteqcs$mg8$01$1@news.t-online.com...
>
[snip]
> Note, you may NOT assume this for other languages.
> (The semantics of OR/AND are interesting)
> eg.
> In C (array refences are based 0)
> if ( myidx < 0 || myarray[myidx] == ' ')
> is doomed to failure, while the C compiler may
> reorder the test sequence :-)
Most of the time the C compiler may reorder; but not
in cases when ||, &&, and some others are involved.
For the given example (myidx < 0) will be evaluated first
and, if true, (myarray[myidx] == ' ') will not be evaluated.
[Harbison & Steele, 7.7 Logical Operator Expressions,
7.12 Order of Evaluation, and 7.12.1 Sequence Points]
| |
| Richard 2007-03-16, 6:55 pm |
| On Mar 17, 7:03 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> Anyway, I like it. One thing that always bugs my in COBOL is "priming"
> reads. For example...
>
> read-next-record
> perform until end-of-file
> perform process-record
> perform read-next-record
> end-perform
>
> Although its so common that any COBOL programmer should know what it's
> doing, I still don't like it.
>
> Of course you could always do this:
>
> perform until end-of-file
> perform read-next-record
> if not end-of-file
> perform process-record
> end-if
> end-perform
>
> But then you are checking the EOF condition twice; once to see if you should
> do process-record and one to see if you should exit the loop.
> Again, yuck!
perform with test after until file-status-byte-1 not = zero
read file next record
at end continue
not at end
process as required
end-read
end-perform
> It looks like in Ada one might do something like this:
>
> Read_Loop :
> loop
> X := Read_Next_Record(record);
> exit Read_Loop when X = EOF;
> Do_Something(record);
> end loop Read_Loop;
>
> Now *that* I can get into.
>
> In C you might do something like this:
>
> while (read_next_record(record) != EOF) {
> do_something(record);
>
> }
> I like that just as well, and perhaps even more than the "loop with
> condition in the middle". But it does rely on the function in the while
> loop returning a result that can be used to check the 'ending' condition.
The problem with the C way is that statements in a condition may be
short-circuited. As the function could produce side effects (for
example putting data into 'record') if it is skipped in a short-
circuit the side effect is not done.
This can be confusing and many langugaes (such as Cobol) disallows
code that could produce side effects in conditions.
> Since COBOL perform statements don't return a value you can't really utilize
> that paradigm. There's always COBOL user-defined functions, but then you
> might end up with a lot of little functions instead of paragraphs. This may
> be good or not good, but doesn't help if you want to stick with
> paragraphs/sections.
>
> Anyway, something like this might be OK:
>
> perform until exit
> perform read-next-record
> if end-of-file
> exit perform
> end-if
> perform process-record
> end-perform
I very much dislike 'exit perform' or indeed 'exit paragraph' or 'exit
section'. The reason is that these statements are position
dependent. That is, if you want to move the block of code from inside
the perform to its own paragraph then the code would need changing.
> A bit verbose, but OK. Of course it's very, very similar to my second
> example above. So much that one would be justified in questioning why we'd
> want to add something new to COBOL for it when we can already do pretty much
> the same thing.
>
> Going with the Ada method you might have this:
>
> perform until exit
> perform read-next-record
> exit perform when end-of-file
> perform process-record
> end-perform
>
> That's pretty nice. Or, if we want to add a new keyword, how about :
>
> loop
> perform read-next-record
> exit loop when end-of-file
> perform process-record
> end-loop
>
> No, I have no hope of COBOL having anything like this. Just pondering...
>
> Then, of course, there's our old friend the GOTO:
>
> read-loop.
> perform read-next-record
> if not end-of-file
> perform process-record
> goto read-loop
> end-if.
>
> While I'd probably never do the above, simply because I've been brainwashed
> into avoiding gotos, I don't really see anything wrong with the above.
> :-)
>
> Oh, and before someone (Pete) mentions in, yes I do like the .NET foreach
> constructs:
>
> C#
> foreach (record rec in rec_file) {
> rec.do_something();
>
> }
Python:
for rec in file:
do_something
> MF NetExpress (COBOL)
> perform varying rec through rec_file
> rec::"do_something"()
> end-perform
>
> That is perhaps the ideal, though it requires OO stuff (iterators and
> what-not).
>
> Well, I better get back to real work. :-)
>
> Frank
| |
| Richard 2007-03-16, 6:55 pm |
| On Mar 17, 8:15 am, "Roger While" <s...@sim-basis.de> wrote:
> "Roger While" <s...@sim-basis.de> schrieb im Newsbeitragnews:eten2e$392$03$1@news.t-online.com...
>
>
> Note, you may NOT assume this for other languages.
> (The semantics of OR/AND are interesting)
> eg.
> In C (array refences are based 0)
> if ( myidx < 0 || myarray[myidx] == ' ')
> is doomed to failure, while the C compiler may
> reorder the test sequence :-)
No. That is wrong. C will guarantee that anything to the left of an
|| (or) or an && (and) will be evaluated before anything to the right
of it. Short-cutting may occur and the expressions to the right may
not be evaluated at all.
| |
| Roger While 2007-03-16, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:12vltcfiepqsf99@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:eteqcs$mg8$01$1@news.t-online.com...
> [snip]
>
> Most of the time the C compiler may reorder; but not
> in cases when ||, &&, and some others are involved.
>
> For the given example (myidx < 0) will be evaluated first
> and, if true, (myarray[myidx] == ' ') will not be evaluated.
>
> [Harbison & Steele, 7.7 Logical Operator Expressions,
> 7.12 Order of Evaluation, and 7.12.1 Sequence Points]
>
Indeed, I stand corrected. The C standard for
AND/OR opertors (as opposed to bit operators)
do left-to-right evaluation.
However, I would NEVER rely on a syntatcal result.
And something more to throw into the discussion
NOT EQUAL ... OR ...
when really is meant
NOT EQUAL ... AND ...
or/and :_)
| |
| Pete Dashwood 2007-03-16, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12vk6ivepdcj338@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:55ua5kF26srs0U1@mid.individual.net...
>
> INITIALIZE WS-BALANCE-X
>
> Actually, if ws-balance-x is initialized, ws-balance will
> have seven spaces followed by 0.00. (Well, technically,
> pedantically, or unambiguously. Your choice! <g> )
I was using "initialized" in the sense of
MOVE SPACES TO WS-BALANCE-X
I realise INITIALIZE would be "safe"... :-)
>
> two
>
> Steve McConnell, "Code Complete", Microsoft Press, 1993,
> page 326, on the subject "When to Use a loop-with-exit Loop",
> says, "A loop-with-exit loop is a loop in which the exit condition
> appears in the middle of the loop rathe than at the beginning or
> at the end. The loop-with-exit lop is available explicity in Ada,
> and you can emulate it [in other langauges]. ...
>
> "The loop-with-exit loop is a one-entry, one-exit, structured
> control construct, and is the preferred kind of loop control in
> Ada programming (Software Productivity Consortium 1989).
> It has been shown to be easier to understand than other kinds
> of loops. A study of student programmers compared this kind
> of loop with those that exited at either the top or bottom
> (Soloway, Bonar, and Ehrlich 1983). Students scored 25
> percent higher on a test of comprehension when loop-with-exit
> loops where used, and the authors of the study concluded that
> the loop-with-exit structure more closely models the way people
> think about iterative control than other loop structures do.
>
> "The loop-with-exit loop isn't widely used yet. The jury is still
> locked in a smoky room arguing about whether it's a good
> practice. Until the jury is in, the loop-with-exit is a good
> technique to have in your programmer's toolbox--as long as
> you use it carefully."
>
> run
>
> Use of the INSPECT statement actually requires two thoughts;
> one for initialization and the other for the inspect itself. This
> form attempts to find an answer by doing the opposite of what
> is desired. ("I don't want to know how many spaces there are;
> I want to know the location of the first non-space character! <g> )
>
> A simple loop requires only one thought; that which is desired.
>
> is
> personal
>
>
>
| |
| Pete Dashwood 2007-03-16, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12vk6ivepdcj338@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:55ua5kF26srs0U1@mid.individual.net...
>
> INITIALIZE WS-BALANCE-X
>
> Actually, if ws-balance-x is initialized, ws-balance will
> have seven spaces followed by 0.00. (Well, technically,
> pedantically, or unambiguously. Your choice! <g> )
>
I covered this in previous response, before I saw the rest of your post...
:-)
> two
>
> Steve McConnell, "Code Complete", Microsoft Press, 1993,
> page 326, on the subject "When to Use a loop-with-exit Loop",
> says, "A loop-with-exit loop is a loop in which the exit condition
> appears in the middle of the loop rathe than at the beginning or
> at the end. The loop-with-exit lop is available explicity in Ada,
> and you can emulate it [in other langauges]. ...
>
> "The loop-with-exit loop is a one-entry, one-exit, structured
> control construct, and is the preferred kind of loop control in
> Ada programming (Software Productivity Consortium 1989).
Preferred by whom? This is bollocks...:-)
And why would I want to emulate Ada (a language that never went anywhere
except on defence contracts) in COBOL or any other language?
> It has been shown to be easier to understand than other kinds
> of loops.
Not by me...:-)
Anything that clutters up code or adds unnecessary statements to it (with
the possible exception of comments, and they should be used and formatted
judiciously) cannot make it clearer or easier to read.
A perform loop has one entry point and the exit is specifically EXIT-PERFORM
or EXIT PERFORM (although I don't like the latter for the same reason that
Richard doesn't; you can't move code about that contains it. If I can avoid
EXIT PERFORM, I will (and do). The example posted has removed this construct
from the original.
>A study of student programmers compared this kind
> of loop with those that exited at either the top or bottom
> (Soloway, Bonar, and Ehrlich 1983). Students scored 25
> percent higher on a test of comprehension when loop-with-exit
> loops where used, and the authors of the study concluded that
> the loop-with-exit structure more closely models the way people
> think about iterative control than other loop structures do.
Oh sure, let's drag programming down to the level of student programmers...
Hey, why not just put an English Language interface over the code then the
little darlings can express their convoluted thought processes to their
hearts content, and still call themselves "programmers"?...Oops, sorry, they
tried that with FOCUS in the early '80s...another lead balloon.
We don't know how these "exit loops" were presented to the students, but I
wouldn't mind betting it WASN'T in COBOL...
>
> "The loop-with-exit loop isn't widely used yet. The jury is still
> locked in a smoky room arguing about whether it's a good
> practice.
And, 14 years later it still hasn't caught on...
Wonder why? :-)
> Until the jury is in, the loop-with-exit is a good
> technique to have in your programmer's toolbox--as long as
> you use it carefully."
ANYTHING in terms of technique or construct is good to have in your toolbox,
as long as you use it carefully...
The nature of computer programming is about taking care.
>
> run
>
> Use of the INSPECT statement actually requires two thoughts;
> one for initialization and the other for the inspect itself.
Two thoughts,eh? Well, we wouldn't want to wear out brain cells unnecssarily
would we?
For me, the initialization of any kind of tally in an INSPECT is so much a
part of the construct that I didn't even bother to add it to the above. I
don't need two thoughts to do this; it is connected in my head through years
of experience. The first time I ran code that failed because the tally
hadn't been initialized (about 35 years ago using EXAMINE) a light flashed
on and the Voice of God said: "Pete, might be a good idea to ALWAYS
initialise tallies before using them. Connect this idea to the EXAMINE
construct."
I NEVER ignore the Voice of God... (Of course I had to update the idea when
the powers-that-be decided INSPECT would replace EXAMINE, but even my
limited mental capacity managed to cope with that particular change... :-))
Seriously, if you are saying that two thoughts are worse than one, I would
respond with: "Not always..."
first thought: "I wonder if the barrel's clean..."
second thought: "Put the safety on."
Certainly a single thought takes less effort, but sometimes the effort is
worth taking.
Besides, brains are designed for thinking and making them do so does no harm
whatsoever. (Making them do so pointlessly, can be discouraging, certainly.)
>This
> form attempts to find an answer by doing the opposite of what
> is desired. ("I don't want to know how many spaces there are;
> I want to know the location of the first non-space character! <g> )
No, the construct understands that the number of leading spaces and the
first non-blank character are inextricably entwined. Finding one derives the
other. There is no "opposite of what I want"; it does EXACTLY what I want.
Furthermore, (and this was my real point) it does so in an easily
assimilable, COBOL-like way, that is likely to make sense to the 3:00
in-the-morning maintenance guy on his fourth cup of coffee...
>
> A simple loop requires only one thought; that which is desired.
It may, certainly.
The example posted was neither simple, nor did it attain that which was
desired, directly. It was obfuscated by a mixture of refmodding with what
was apparently a subscript (but not formatted as a refmodded subscript would
actually require), an unnecessary if, an EXIT PERFORM, and a "subscript"
that was really an offset.
It is a very wise person who recognises that which is desired.
The truly enlightened are beyond desire. :-)
Me, I just write code to do what I want, trying to keep it as succinct as
possible (unlike the long musings I post here :-))
Pete.
| |
| Frank Swarbrick 2007-03-16, 6:55 pm |
| >>> On 3/16/2007 at 2:04 PM, in message
<1174075481.582976.54930@l77g2000hsb.googlegroups.com>,
Richard<riplin@Azonic.co.nz> wrote:
> On Mar 17, 7:03 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
>
>
> should
>
> perform with test after until file-status-byte-1 not = zero
> read file next record
> at end continue
> not at end
> process as required
> end-read
> end-perform
True enough, and OK as long as you use DECLARATIVES to check for unexpected
file errors. But this is also a special case in that READ is a COBOL verb
with special 'error handling' clauses. Consider doing an SQL fetch instead
of a COBOL read
perform until not sql-successful
perform fetch-next-record
if sql-successful
perform process-record
end-if
end-perform
>
> condition.
>
> The problem with the C way is that statements in a condition may be
> short-circuited. As the function could produce side effects (for
> example putting data into 'record') if it is skipped in a short-
> circuit the side effect is not done.
>
> This can be confusing and many langugaes (such as Cobol) disallows
> code that could produce side effects in conditions.
Can you give an example of this? I have heard of this, but can't think of
an example at the moment.
> utilize
you[color=darkred]
[color=darkred]
> may
>
> I very much dislike 'exit perform' or indeed 'exit paragraph' or 'exit
> section'. The reason is that these statements are position
> dependent. That is, if you want to move the block of code from inside
> the perform to its own paragraph then the code would need changing.
I assume you are referring to this type of "movement"
perform until exit
perform read-and-process
end-perform
| |
| Pete Dashwood 2007-03-16, 9:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:NOidnVcZELCzAGfYnZ2dnUVZ_tninZ2d@co
mcast.com...
> Roger While wrote:
>
> If it's all spaces, the length will be zero - am I missing something?
>
Yes.
You have a compound condition using OR but you have the range check on the
subscript/index AFTER the check on what you're really looking for. :-)
In this case, it is not a problem, but in other cases it could be. (And I
can promise you, you will crash and burn on this one day if you don't change
the habit :-))
Always put the range check BEFORE the condition...
UNTIL WS-STRING-IDX < 1
OR
WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
Incidentally, Daniel, when did you take to using SECTION without paragraphs,
and EXIT SECTION, rather than a single exit point?
This is not a step forward in your COBOL evolution... :-)
Pete. (Representing the Style Police :-))
| |
| Pete Dashwood 2007-03-16, 9:55 pm |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:etevqr$8go$00$1@news.t-online.com...
>
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:12vltcfiepqsf99@corp.supernews.com...
>
> Indeed, I stand corrected. The C standard for
> AND/OR opertors (as opposed to bit operators)
> do left-to-right evaluation.
>
> However, I would NEVER rely on a syntatcal result.
>
> And something more to throw into the discussion
> NOT EQUAL ... OR ...
>
> when really is meant
> NOT EQUAL ... AND ...
>
> or/and :_)
>
>
The old "DeMorgan"-got-me-again error... :-)
Sadly these days they don't seem to learn Boolean Algebra and Propositional
Calculus.
Over the years, on a number of sites, I have run lunchtime workshops for
programmers in the basics... (Bring your lunch, and have an informal
learning experience while you eat). They have been well attended and usually
fun.
The simple laws of Boolean Algebra can make all the difference when it comes
to simplifying very complex IFs and PERFORMs, and the intuitively unlikely
formulation of De morgan's laws often comes as a surprise.
Once they see this, they never make that mistake again.
(A.B)' = A' + B' [De Morgan 1]
(A + B)' = A' . B' [De Morgan 2]
(For those of a COBOL (rather than mathematical) persuasion, read . as AND,
+ as OR and ' as NOT.)
Pete.
| |
|
| > But now there is a need to communicate with a streaming output and
> maybe re-thinking a bit at a time is not the optimal way. Enhancing
> the old way of doing this a bit won't suffice.
Well, based on that line of thought, you might as well just rewrite
everything in Java or C# and be done with it.
| |
| Rick Smith 2007-03-16, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:560j8gF252dj0U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12vk6ivepdcj338@corp.supernews.com...
so[color=darkred]
his[color=darkred]
and[color=darkred]
>
> I covered this in previous response, before I saw the rest of your post...
> :-)
>
following[color=darkred]
>
> Preferred by whom? This is bollocks...:-)
The full reference, given in the bibliography, is:
Software Productivity Consortium. 1989. "Ada Quality
and Style Guidlines for Professional Programmers."
New York: Van Nostrand Reinhold.
My guess would be Professional Ada Progammers!
> And why would I want to emulate Ada (a language that never went anywhere
> except on defence contracts) in COBOL or any other language?
Because, as mentioned next, "It has been shown to be
easier to understand ...."
>
> Not by me...:-)
>
> Anything that clutters up code or adds unnecessary statements to it (with
> the possible exception of comments, and they should be used and formatted
> judiciously) cannot make it clearer or easier to read.
>
> A perform loop has one entry point and the exit is specifically
EXIT-PERFORM
> or EXIT PERFORM (although I don't like the latter for the same reason that
> Richard doesn't; you can't move code about that contains it. If I can
avoid
> EXIT PERFORM, I will (and do). The example posted has removed this
construct
> from the original.
>
>
> Oh sure, let's drag programming down to the level of student
programmers...
Or, help drag student programmers up to the level of
professional programmers, by using structures those
students comprehend better.
> Hey, why not just put an English Language interface over the code then the
> little darlings can express their convoluted thought processes to their
> hearts content, and still call themselves "programmers"?...Oops, sorry,
they
> tried that with FOCUS in the early '80s...another lead balloon.
>
> We don't know how these "exit loops" were presented to the students, but I
> wouldn't mind betting it WASN'T in COBOL...
While the construct didn't make it into the COBOL
PERFORM statement until 2002, there may have
been many cases that were removed when some
began "persecuting" those who used GO TO
statements. Some COBOL examples might have
been used since the results were published in 1983.
>
> And, 14 years later it still hasn't caught on...
Except in Ada, C, C++, (if I recall correctly) Java,
(most likely) C#, some COBOL implementations,
etc., where programmer's recognize its value.
{For C and some others, think "break".]
> Wonder why? :-)
>
>
>
> ANYTHING in terms of technique or construct is good to have in your
toolbox,
> as long as you use it carefully...
>
> The nature of computer programming is about taking care.
>
>
of[color=darkred]
about[color=darkred]
>
> Two thoughts,eh? Well, we wouldn't want to wear out brain cells
unnecssarily
> would we?
>
> For me, the initialization of any kind of tally in an INSPECT is so much a
> part of the construct that I didn't even bother to add it to the above. I
> don't need two thoughts to do this; it is connected in my head through
years
> of experience. The first time I ran code that failed because the tally
> hadn't been initialized (about 35 years ago using EXAMINE) a light flashed
> on and the Voice of God said: "Pete, might be a good idea to ALWAYS
> initialise tallies before using them. Connect this idea to the EXAMINE
> construct."
Is that initialize to space <g>, 0, or 1?
> I NEVER ignore the Voice of God... (Of course I had to update the idea
when
> the powers-that-be decided INSPECT would replace EXAMINE, but even my
> limited mental capacity managed to cope with that particular change...
:-))
Was that the Voice that told you to add END-INSPECT,
which is not part of the language? <g>
> Seriously, if you are saying that two thoughts are worse than one, I would
> respond with: "Not always..."
>
> first thought: "I wonder if the barrel's clean..."
> second thought: "Put the safety on."
>
> Certainly a single thought takes less effort, but sometimes the effort is
> worth taking.
>
> Besides, brains are designed for thinking and making them do so does no
harm
> whatsoever. (Making them do so pointlessly, can be discouraging,
certainly.)
>
>
> No, the construct understands that the number of leading spaces and the
> first non-blank character are inextricably entwined. Finding one derives
the
> other. There is no "opposite of what I want"; it does EXACTLY what I
want.
>
> Furthermore, (and this was my real point) it does so in an easily
> assimilable, COBOL-like way, that is likely to make sense to the 3:00
> in-the-morning maintenance guy on his fourth cup of coffee...
For those familiar with the pre-COBOL 85 idioms!
>
> It may, certainly.
>
> The example posted was neither simple, nor did it attain that which was
> desired, directly. It was obfuscated by a mixture of refmodding with what
> was apparently a subscript (but not formatted as a refmodded subscript
would
> actually require), an unnecessary if, an EXIT PERFORM, and a "subscript"
> that was really an offset.
Prior to COBOL 85, it was necessary to redefine
text fields as individual characters in order to build
certain types of "strings". These "strings" were then
built by using subscripts to copy the characters from
the various sources to the destination "string".
Reference modification eliminates the necessity of
redefining such fields. So, yes, there are times when
reference modification may look like subscripts to
those used to the "old" way of doing things. <g>
Some of us are no longer tied to the ways of the
past! <g>
>
> It is a very wise person who recognises that which is desired.
>
> The truly enlightened are beyond desire. :-)
>
> Me, I just write code to do what I want, trying to keep it as succinct as
> possible (unlike the long musings I post here :-))
| |
|
| Pete Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:NOidnVcZELCzAGfYnZ2dnUVZ_tninZ2d@co
mcast.com...
>
> Yes.
>
> You have a compound condition using OR but you have the range check on the
> subscript/index AFTER the check on what you're really looking for. :-)
>
> In this case, it is not a problem, but in other cases it could be. (And I
> can promise you, you will crash and burn on this one day if you don't change
> the habit :-))
>
> Always put the range check BEFORE the condition...
>
> UNTIL WS-STRING-IDX < 1
> OR
> WS-STRING-CHAR (WS-STRING-IDX) NOT = SPACE
I've seen this from others too - thanks to all for that. The reason I
didn't see it is that I never performed that logic on something that was
all spaces. I had a separate check for that, and appended a CR/LF to
the buffer I was accruing. :)
> Incidentally, Daniel, when did you take to using SECTION without paragraphs,
> and EXIT SECTION, rather than a single exit point?
Just following the OP's style, to illustrate what I was saying in a
style he would find comfortable.
> This is not a step forward in your COBOL evolution... :-)
Cuando en México (o México Nuevo), habla español... :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Richard 2007-03-16, 9:55 pm |
| On Mar 17, 11:41 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "LX-i" <lxi0...@netscape.net> wrote in message
>
> news:NOidnVcZELCzAGfYnZ2dnUVZ_tninZ2d@co
mcast.com...
>
>
>
>
>
>
> Yes.
>
> You have a compound condition using OR but you have the range check on the
> subscript/index AFTER the check on what you're really looking for. :-)
>
> In this case, it is not a problem, but in other cases it could be. (And I
> can | | |