Cobol - been a long time

Author

been a long time

Moe

2005-09-13, 6:55 pm

It's been a long time since I've programmed in Cobol, and have a
question for the group.

We have a Pic X(32) field that we are filling with 8-10 characters.
No problem there.
What we need in the output file is those 8-10 characters followed by as
many spaces as are needed to get to the 32 char field length.

Any quick and easy way to do this?

Sorry for such a newbie question.
-Moe

Binyamin Dissen

2005-09-13, 6:55 pm

On 13 Sep 2005 08:40:36 -0700 "Moe" <moesplace@moetele.com> wrote:

:>It's been a long time since I've programmed in Cobol, and have a
:>question for the group.

:>We have a Pic X(32) field that we are filling with 8-10 characters.
:>No problem there.
:>What we need in the output file is those 8-10 characters followed by as
:>many spaces as are needed to get to the 32 char field length.

:>Any quick and easy way to do this?

It is automatic.

A move into a 32 character field will truncate longer fields and pad shorter
fields.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Moe

2005-09-13, 6:55 pm

But for some reason, it is ignoring the "spaces" when it writes the
record out... any clues?

Frederico Fonseca

2005-09-13, 6:55 pm

On 13 Sep 2005 09:28:09 -0700, "Moe" <moesplace@moetele.com> wrote:

>But for some reason, it is ignoring the "spaces" when it writes the
>record out... any clues?
Yes.
This is dependent on the file format used, and on the compiler vendor
used, and on the OS used.

If using a line sequential file for example, trailing spaces are
removed.

So please post your SELECT, your FD and your vendor/version/OS used

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

William M. Klein

2005-09-13, 6:55 pm

Can you show us the actual fields being moved and the MOVE statements?

If you move a 32-byte field to a 32-byte field, it will move the WHOLE "input"
field, not just the non-blank data. If you move an 8-byte field to a 32-byte
field, it will ALWAYS "space pad". If you have trailing spaces in a LINE
SEQUENTIAL file it may (or may not, depends on lots of stuff) truncating
trailing spaces.

--
Bill Klein
wmklein <at> ix.netcom.com
"Moe" <moesplace@moetele.com> wrote in message
news:1126632046.419760.86770@g14g2000cwa.googlegroups.com...
> Sun Solaris 8 on SPARC Using MicroFocus Cobol compiler.
>
> SELECT APIFILE-FILE ASSIGN TO DISK
> ORGANIZATION LINE SEQUENTIAL
> STATUS WS-WORK-FILE-STATUS.
>
> FD APIFILE-FILE VALUE OF
> FILE-ID APF-APIFILE-NAME.
> 01 APIFILE-REC PIC X(289).
>

Richard

2005-09-13, 6:55 pm

> ORGANIZATION LINE SEQUENTIAL

If you want records that are of a particular size then you need to use
'sequential' (remove 'line' but you will have to add your own cr/lf
line terminators if these are required. If the records are to be
various lengths then the system will probably add record headers as it
needs to know where each record starts and ends and this will probably
not be what you want.

HeyBub

2005-09-13, 6:55 pm

Moe wrote:
> Sun Solaris 8 on SPARC Using MicroFocus Cobol compiler.
>
> SELECT APIFILE-FILE ASSIGN TO DISK
> ORGANIZATION LINE SEQUENTIAL
> STATUS WS-WORK-FILE-STATUS.
>
> FD APIFILE-FILE VALUE OF
> FILE-ID APF-APIFILE-NAME.
> 01 APIFILE-REC PIC X(289).

Some compilers (you evidently have one) believe that trailing spaces should
be removed from "LINE SEQUENTIAL" files because the compiler-generated code
will re-attach the spaces when the file is read. These compilers do this for
the defensible reason of saving space.

Some compilers do not do this, writing the entire record even if the record
is entirely blank.

Two solutions come to mind:

1. Change the ORGANIZATION to SEQUENTIAL. You will have to increase the
record length by two bytes and manually add CR/LF bytes at the end (if those
are the characters delimiting each record), or

2. Insert a special, non-confusing, terminal character (HIGH-VALUES?) as the
last byte when the last byte is a blank and remove this sentinel charcter
first thing when the file is read.

Moe

2005-09-13, 6:55 pm

Yes, we want fixed-length records, just with about 22 or 23 (depending
on size of last field) spaces at the end of them.
I will try changing the ORG to SEQ and manually put on the CR/LF bytes.
Thanks... Will let you know how it goes.

Sponsored Links