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

Author

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

GeneralBullmoose

2005-05-24, 8:55 pm

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!

William M. Klein

2005-05-24, 8:55 pm

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!
>

GeneralBullmoose

2005-05-24, 8:55 pm

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

HeyBub

2005-05-25, 3:55 am

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.

Richard

2005-05-25, 3:55 am

> 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).

GeneralBullmoose

2005-05-25, 3:55 pm

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)

Richard

2005-05-25, 8:55 pm

> 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.

Chuck Stevens

2005-05-25, 8:55 pm

"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

William M. Klein

2005-05-25, 8:55 pm

Chuck,
My memory of the "issues" that caused the "don't use numeric/integer functions
in a MOVE" were that the actual "nature" of the "temporary data item" created 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 went
with the SIMPLEST rule which was that you couldn't use them - EXCEPT where an
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 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.
>
>
> 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
>
>

HeyBub

2005-05-25, 8:55 pm

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.

Richard

2005-05-25, 8:55 pm

@> 01 THE-NOTE-STRING-COMPLETE PIC X(1900).
@> 01 PNOTES-NEW-OUT-RECORD.
@> 05 WK3-PNOTES-COMPLETE-LINE PIC X(1900).

@> MOVE FUNCTION LENGTH(THE-NOTE-STRING-COMPLETE)
@> TO WK3-PNOTES-COMPLETE-LINE

[color=darkred]
> 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.

He may have been forgiven for thinking that it would give the length of
the text within the field but he seemed to be attempting to use the
MOVE to move only that text as well as set the length of a possible
variable length depending field that is not even given.

> is a common implementor extension

It may be common, but it is not universal. And being common is only
relevant if it exists within the particular compiler that has been
specified.

Chuck Stevens

2005-05-25, 8:55 pm

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

>
> It may be common, but it is not universal. And being common is only
> relevant if it exists within the particular compiler that has been
> specified.

It was your description of it as a "microfocusism" that got my attention. I
don't think it's anything like unique to Micro Focus, nor do I think
everyone else that had that extension did so because they thought it
efficacious to follow Micro Focus' example in this area -- or even were
aware of the fact that Micro Focus COBOL allowed it. I know it's not
'85/'89 standard COBOL; I addressed that.

-Chuck Stevens

GeneralBullmoose

2005-05-26, 8:55 pm

Wow! I appreciate everyone's help with this. I will abandon the "MOVE
FUNCTION" idea and work on scanning backwards for the last non-space or
the other possiblities. I'm just getting back with this after a couple
of years being away from it, so I'm a bit slow.

Thank you!

docdwarf@panix.com

2005-05-26, 8:55 pm

In article <1117137758.005543.46980@g44g2000cwa.googlegroups.com>,
GeneralBullmoose <psmithphil@gmail.com> wrote:

[snip]

>Thank you!

No prob... after all, if it's good for you then it's good for the USA.

DD

GeneralBullmoose

2005-05-27, 3:55 pm

docdwarf@panix.com wrote:
>
> No prob... after all, if it's good for you then it's good for the USA.
>
> DD

Thank you! I'm glad you see it my way! LOL!

General Bullmoose

docdwarf@panix.com

2005-05-27, 3:55 pm

In article <1117201034.691956.225210@g14g2000cwa.googlegroups.com>,
GeneralBullmoose <psmithphil@gmail.com> wrote:
>
>
>docdwarf@panix.com wrote:
>
>Thank you! I'm glad you see it my way! LOL!

Actually it is a curious coincidence... I was in a waiting-room last w

and I had forgotten my copy of The Economist and was forced to read the
magazines on the table, one of them contained an article:

http://www.ew.com/ew/article/review...6115,1049663_21|107186||0_0_,00.html

.... and it reminded me of the song.

(Bosomy babes! Grotesquely fake beards! Scads of Yokum hokum... is this
Culture or is this Culture? Those interested in this now-arcane Americana
might look to http://www.dvdsavant.com/s1567abne.html )

DD

Richard

2005-05-29, 8:55 am

Sponsored Links