In Cobol, large amount of spaces between records due to variable definition

I am building a variable that gets notes from an input file.  The
variable may end up containing notes that may be 1 character or made up
of up to 1900 characters.  I use this one variable for writing to an
output file.  In Cobol, I'm assuming I have to define this variable
in the Working-Storage:
01  THE-NOTE-STRING-COMPLETE             PIC X(1900).

I'm assuming I have to make it this variable 1900 characters since
the notes can get that big.  They are then written to the output file:
FD  PNOTES-NEW-OUT
LABEL RECORDS ARE STANDARD.
01  PNOTES-NEW-OUT-RECORD.
05  WK3-PNOTES-COMPLETE-LINE         PIC X(1900).

When it writes to the output file, due to the variable being defined at
1900 characters, there may be a large amount of spaces between records
because the previous record has only a small amount of notes.  In the
example below, the "~PRICE VALID TILL STOCK OUT" is the only notes
for that record, so there are almost 1900 spaces between the end of
that record and the next:

 ===========EXAMPLE======================
==
~PRICE VALID TILL STOCK OUT


Up to almost 1900 spaces between the 2 records!!


HAZARDOUS(1) MTRL, PACK PER CFR~TOLUENE(1); FLASH POINT 6 TO END OF
LINE~SHIP(1)

==========END OF EXAMPLE===================

I want all the trailing spaces in each record eliminated.  I don't
know how this can be done since the variable is defined at 1900
characters.  And I didn't think Cobol allowed you to have a
"variable-sized" variable.  I feel like I'm going about this in
the wrong manner and don't know how to remedy this issue.  Can you
help?   Thank you!

Check out the

RECORD VARYING IN SIZE DEPENDING ON

feature of the FD.

(This assumes you have an '85 Standard compiler)

--
Bill Klein
wmklein <at> ix.netcom.com
"GeneralBullmoose" <psmithphil@gmail.com> wrote in message
news:1116961920.069053.271860@g44g2000cwa.googlegroups.com...
>I am building a variable that gets notes from an input file.  The
> variable may end up containing notes that may be 1 character or made up
> of up to 1900 characters.  I use this one variable for writing to an
> output file.  In Cobol, I'm assuming I have to define this variable
> in the Working-Storage:
>       01  THE-NOTE-STRING-COMPLETE             PIC X(1900).
>
> I'm assuming I have to make it this variable 1900 characters since
> the notes can get that big.  They are then written to the output file:
> FD  PNOTES-NEW-OUT
>    LABEL RECORDS ARE STANDARD.
> 01  PNOTES-NEW-OUT-RECORD.
>    05  WK3-PNOTES-COMPLETE-LINE         PIC X(1900).
>
> When it writes to the output file, due to the variable being defined at
> 1900 characters, there may be a large amount of spaces between records
> because the previous record has only a small amount of notes.  In the
> example below, the "~PRICE VALID TILL STOCK OUT" is the only notes
> for that record, so there are almost 1900 spaces between the end of
> that record and the next:
>
>  ===========EXAMPLE======================
==
> ~PRICE VALID TILL STOCK OUT
>
>
> Up to almost 1900 spaces between the 2 records!!
>
>
> HAZARDOUS(1) MTRL, PACK PER CFR~TOLUENE(1); FLASH POINT 6 TO END OF
> LINE~SHIP(1)
>
> ==========END OF EXAMPLE===================
>
> I want all the trailing spaces in each record eliminated.  I don't
> know how this can be done since the variable is defined at 1900
> characters.  And I didn't think Cobol allowed you to have a
> "variable-sized" variable.  I feel like I'm going about this in
> the wrong manner and don't know how to remedy this issue.  Can you
> help?   Thank you!
>

Thank you, Bill!   I have the '85 compiler.  I will check this out
immediately.

GeneralBullmoose wrote:
> I am building a variable that gets notes from an input file.  The
> variable may end up containing notes that may be 1 character or made
> up of up to 1900 characters.  I use this one variable for writing to
> an output file.  In Cobol, I'm assuming I have to define this variable
> in the Working-Storage:
>       01  THE-NOTE-STRING-COMPLETE             PIC X(1900).
>
> I'm assuming I have to make it this variable 1900 characters since
> the notes can get that big.  They are then written to the output file:
> FD  PNOTES-NEW-OUT
>    LABEL RECORDS ARE STANDARD.
> 01  PNOTES-NEW-OUT-RECORD.
>    05  WK3-PNOTES-COMPLETE-LINE         PIC X(1900).

Um, check your compiler. Several compilers, perhaps as an option, will
truncate trailing blanks on output and pad the record on input.

> I want all the trailing spaces in each record eliminated.

You can have variable length records, possibly in a variety of ways.

If you have an extension of ORGANIZATION LINE SEQUENTIAL then this may
strip all trailing spaces and terminate the record with CR/LF or just
LF. (Note you may need a run-time environment variable to ensure
trailing space removal on Fujitsu).

If the file system allows variable sequential records then you may do
it with the FD record having OCCURS 1 TO 1900 DEPENDING ON something.
The WRITE will output the specified size but may need to add a record
header that specifies the length (something has to indicate the boundry
between records).

Thank you, all!  My compiler is AcuCobol-85 runtime version 2.4.3 on
Windows.  Apparently it is old as I get the error message below when I
compile:
CI907sm.cbl, line 176: Undefined data item: FUNCTION
CI907sm.cbl, line 176: TO expected, LENGTH found
CI907sm.cbl, line 176: Verb expected, LENGTH found

These are the lines (inside an "IF" statement) that generate the error.
It appears my compiler doesn't recognize what "FUNCTION" is.
MOVE FUNCTION LENGTH(THE-NOTE-STRING-COMPLETE)
TO WK3-PNOTES-COMPLETE-LINE

I purchased MicroFocus Cobol a couple of years back but it errored on
the installation and would never install.  I got put on other projects
and am now getting back to Cobol.  I will try to get MicroFocus Cobol
running so I can continue with this.

I appreciate everyone's efforts on helping me!  Thank you!  Wish me
luck!  :o)

>  It appears my compiler doesn't recognize what "FUNCTION" is.
> MOVE FUNCTION LENGTH(THE-NOTE-STRING-COMPLETE)
>               TO WK3-PNOTES-COMPLETE-LINE

It may not have the intrinsic functions, or it may require them to be
used correctly in a COMPUTE statement: COMPUTE field-length = FUNCTION
LENGTH(field)

Using numeric functions in a MOVE is a microfocusism and should not be
attempted on any code that you want to have as portable.

However, you would probably find this to be useless anyway as it will
give you an answer of 1900.   Of course this can then be used as the
start point of a PERFORM scanning backwards for the last non-space.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117048929.903189.89990@o13g2000cwo.googlegroups.com...

> It may not have the intrinsic functions, or it may require them to be
> used correctly in a COMPUTE statement: COMPUTE field-length = FUNCTION
> LENGTH(field)

> Using numeric functions in a MOVE is a microfocusism and should not be
> attempted on any code that you want to have as portable.

The relaxation of the restriction that a numeric or integer function may
only appear in an arithmetic expression is a common implementor extension to
the '89 intrinsic function amendment by no means limited to Micro Focus'
implementation.   Moreover, ISO/IEC 1989:2002 does not include that
restriction, and includes an example of a numeric function used as a sending
data item in a MOVE statement in the Concepts appendix (page 741, E.6,
Intrinsic function facility).   I think one of the reasons the restriction
was lifted is that it was arguably capricious:  functions MAX and MIN could
be used as sending fields in MOVE statements so long as their arguments were
alphanumeric, but the same functions could only be used in arithmetic
expressions when the arguments to them were numeric.

> However, you would probably find this to be useless anyway as it will
> give you an answer of 1900.   Of course this can then be used as the
> start point of a PERFORM scanning backwards for the last non-space.

I'm not sure what you're asserting here, but according to both COBOL
standards that include it, FUNCTION LENGTH of a record containing an ODO
item gives the current length, not the maximum length.

-Chuck Stevens

Chuck,
My memory of the "issues" that caused the "don't use numeric/integer functio
ns
in a MOVE" were that the actual "nature" of the "temporary data item" create
d by
these functions was totally "unknown".

Therefore, things like

Function Length (Function Integer-of-date (whatever))

or

Move Function Random (1:2) to someplace

or

Call "XYZ" using By Content Function Max (Num1 Num2)

would cause problems.  Therefore, rather than figure out "rules" that would
allow these in some places, but not allow them in others - the committees we
nt
with the SIMPLEST rule which was that you couldn't use them - EXCEPT where a
n
arithmetic expression could be use (which already avoided all of the "above"
problems).

P.S.  IBM (mainframe at least) compilers still enforce this rule - as do
Workstation compilers when running in "IBM compatible" mode.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:d72l8h$1uhh$1@si05.rsvl.unisys.com...
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1117048929.903189.89990@o13g2000cwo.googlegroups.com...
> 
> 
>
> The relaxation of the restriction that a numeric or integer function may
> only appear in an arithmetic expression is a common implementor extension 
to
> the '89 intrinsic function amendment by no means limited to Micro Focus'
> implementation.   Moreover, ISO/IEC 1989:2002 does not include that
> restriction, and includes an example of a numeric function used as a sendi
ng
> data item in a MOVE statement in the Concepts appendix (page 741, E.6,
> Intrinsic function facility).   I think one of the reasons the restriction
> was lifted is that it was arguably capricious:  functions MAX and MIN coul
d
> be used as sending fields in MOVE statements so long as their arguments we
re
> alphanumeric, but the same functions could only be used in arithmetic
> expressions when the arguments to them were numeric.
> 
>
> I'm not sure what you're asserting here, but according to both COBOL
> standards that include it, FUNCTION LENGTH of a record containing an ODO
> item gives the current length, not the maximum length.
>
>    -Chuck Stevens
>
>

GeneralBullmoose wrote:
> Thank you, all!  My compiler is AcuCobol-85 runtime version 2.4.3 on
> Windows.  Apparently it is old as I get the error message below when I
> compile:
> CI907sm.cbl, line 176: Undefined data item: FUNCTION
> CI907sm.cbl, line 176: TO expected, LENGTH found
> CI907sm.cbl, line 176: Verb expected, LENGTH found
>
> These are the lines (inside an "IF" statement) that generate the
> error. It appears my compiler doesn't recognize what "FUNCTION" is.
> MOVE FUNCTION LENGTH(THE-NOTE-STRING-COMPLETE)
>               TO WK3-PNOTES-COMPLETE-LINE
>

Uh, even if this worked, you already know the length of the field. Here's
one way.

FD  OUT-FILE.
01  OUT-REC.
02  Filler occurs 1 to 1900 depending on OUT-LEN Pic X.

---
01  TEMP-DATA Pic X(1900).
01  CRLF  Pic X(2) Value X'0D0A'.


Move Low-Values to TEMP-DATA
(build record in TEMP-DATA).
Perform FixRec.
...

FixRec.
MOVE 0 TO OUT-LEN.
Inspect TEMP-DATA Tallying OUT-LEN for Characters Before Initial
Low-Values.
Move TEMP-DATA to OUT-REC.
Add 2 to OUT-LEN
Move CRLF to OUT-REC(OUT-LEN - 2:2).
Write OUT-REC.