× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Tom,



Thanks for the additional explanation.



Michael



-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Wednesday, April 22, 2009 6:13 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: Re: [COBOL400-L] Message SubFile



Michael Smith wrote:



The coding error :



DISPLAY-001.

MOVE SPACES TO FLD1 OF FMT1-O.

WRITE DISPLAY-RECORD FORMAT IS "FMT1".

MOVE 'MSGSFLCBL' TO PGMQ OF MSGSFLC-O.

WRITE DISPLAY-RECORD

FORMAT IS "MSGSFLC"

INDICATORS ARE WS-INDICATORS.

READ DISPLAY-FILE

INDICATORS ARE WS-INDICATORS.



Michael:



I'm guessing that the error is the mismatch between 'MSGSFLCBL' and

the Identification Division Program-ID, which is 'SFLCBL'. The error

can be eliminated by changing either or both so that they match and

also making sure that the *MODULE and *PGM are created as the same

name used for Program-ID.



As written, the Program-ID becomes the 'procedure name' that is in

the call stack -- but only if you compile as ILE. If you compile as

ILE, you'll want to ensure that *PGM, *MODULE, procedure and subfile

SFLPGMQ names/values are all what you want them to be.



If you compile as OPM COBOL, everything should work as written.



#2 was the result of using



DATA DIVISION.

FILE SECTION.

FD DISPLAY-FILE01 DISPLAY-RECORD.



LABEL RECORDS ARE STANDARD.

01 DISPLAY-RECORD.

COPY DDS-ALL-FORMATS OF FS2CBL.



Thanks to Jerry Thomas for point the following:



COPY DDS-ALL-FORMATS OF FS2CBL



05 fs2cbl-record pic x(??).

05 FMT1-I redefines FS2CBL-RECORD.

05 FMT1-O redefines FS2CBL-RECORD.

06 SCFIELD pic x(10)



So when I moved values to the two fields, one "appeared" to be corrupted.



The resolution was:



always copy my different formats into a different are of working storage
and

then reference them on the write. This keeps from overlaying data buffer.



FD SCREEN-FILE LABEL RECORDS ARE OMITTED.



01 SCREEN-RECORD PIC X(999).



WORKING-STORAGE SECTION.



01 DSPFMTA.

COPY DD-DSPFMTA-O OF DSPEX05.



01 DSPFMTB.

COPY DD-DSPFMTB-I-O OF DSPEX05.



01 DSPFMTC.

COPY DD-DSPFMTC-I-O OF DSPEX05.



01 MSGFLC.

COPY DD-MSGFLC-I-O OF DSPEX05.



.



WRITE SCREEN-RECORD FROM MSGFLC

FORMAT IS "MSGFLC"

INDICATORS ARE WS-SCREEN-INDICATORS.



CALL "CLRMSG".



WRITE SCREEN-RECORD FROM DSPFMTC

FORMAT IS "DSPFMTC"



Yes, the definitions in the File Section are essentially actual file

I/O buffers (or pretty close to them). You can perform data

operations there, but it's generally advisable to WRITE FROM and

READ INTO separate Working-Storage Section areas.



RPG is well known for moving data elements out of the file buffer

areas into variables that are maintained in separate memory. COBOL

allows you to choose not to do that, and can make shooting yourself

in the foot much easier.



Tom Liotta




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.