Re: Using one Update Program (Jon Paris) -- COBOL400-L

I won't answer your points directly Jeff - rather I'll just try and explain what you are seeing.

I had forgotten that you were using your UPDATEPRO program to read the file before the update so ...

Let's assume that you pass the record area (say 100 bytes) as a parm to UPDATEPRO. What is actually passed is a pointer - note that ZERO information about length or anything else is passed. In UPDATEPRO (because it uses the new record format) that same record is (say) 120 bytes. The only thing the compiler knew about when it compiled UPDATEPRO was the length it was given (120) so when it moves data to the parm it moves 120 bytes. But back in the caller the storage allocation was only 100 bytes - so the next 20 bytes belonging to something just got nuked. If you then change some data in that record in the caller and pass it back to UPDATEPRO it will still see the corrupted memory and will write that to disk - hence your 24 value didn't change. In your current scenario it may be that those 20 bytes don't "matter". But they will in another program and it may take some hapless programmer who comes after you a long time to work it out.

Best example of this was something I saw while working on the COBOL compiler team. Customer had a program that had been "working" for seven years. They changed the value of one literal and recompiled. No test needed - just changed a literal from 0.75 to 0.78. Meanwhile back in production all hell broke loose. Why? For 7 years the program had been corrupting storage as described above. But the area of storage corrupted was the print buffer - and it was space filled before each line was built - so no harm no foul. But in that 7 years the compiler had changed how it generated its storage definitions - and now it wasn't a print buffer that was being corrupted but a collection of pointers used in program calls. Made for an interesting debug scenario.

There are at least three options I can think of:

1) Recompile all affected objects when you change a file

2) Use logicals to ignore the additional fields

3) Use SQL

The one option you should _not_ use is the one you are using now - i.e. lying to the compiler <grin>

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

On Jan 19, 2011, at 2:02 PM, Jeff Buening wrote:

Thanks Jon for your response I kind of have the feeling it isn't correct
just trying to understand the results I am getting. Young COBOL :) person
trying to understand the process. Have a few more questions inline....

Was not for sure if compiling "UPDATEPRO"
and not "PROGRAMA" would cause that new field in FILEA to be spaced out

or

not with the 01 level MOVE in "UPDATEPRO"?

No - it won't be space filled - it will be garbage filled (the garbage may

of course if you are lucky be >spaces!). All that is being passed to
UPDATEPRO is the pointer to the beginning of the field. Since that field

is longer in UPDATEPRO than PROGRAMA when you do the move you will pick up

whatever garbage happens to be >beyond the end of the original storage.

So when I ADDED the field to FILEA and only compiled the "UPDATEPRO", the
calling program "PROGRAMA" sent over in linkage the "FILEA" format(address
in storage) with one less field then in "UPDATEPRO". Given I don't care
that "PROGRAMA" doesn't know anything about the new field, I just don't
want it to mess up something in that New Field when I do the read, write,
REWRITE etc.. in "UPDATEPRO". When running a test the New Field still
stayed the same value "24" as it was. So the garbage I got on the REWRITE
for that example was lucky and the correct value "24"? So this doesn't
mean that every time "PROGRAMA" with one less field calls "UPDATEPRO" and a
REWRITE happens it would leave that New field as it is "24"? Or worse yet
write garbage in that field that another program couldn't reference?

So I am thinking setting up like this will work in reducing compiles.

Even

though I added a field to the FILEA, it didn't mess up the call between

the

two programs or Read, Rewrite etc?

The fact that nothing blew up doesn't mean it worked correctly.

Yes I also checked to see that the New field value stayed the same and it
did, but I guess I can't be for sure that the garbage on the REWRITE next
time will be the correct value.

Yes I also check the New Field value and it was still the same as before
the REWRITE, so I guess in my example I am just getting lucky the garbage
is the same as it was when first written out?

Am I assuming correctly or can anyone tell me I might be missing

something

or could have problems with this?

You're getting garbage in the new fields whenever you write or update

them. That's rarely a good idea.

In my opinion the amount of time you might save in recompiles is likely to

disappear in a hurry when a weird >bug is introduced by such coding
techniques.

Lying to the compiler is rarely a good idea. The only time I would even

consider this approach worthwhile is if >the file is only being read and
the calling program doesn't need the data.

So am I thinking correctly using Logical files with explicit defined fields
in programs (all by themselves) that are not passing the data structure
around in Linkage to reduce compiles there?

And if I am passing data structures around between programs, whether I have
the I/O on files in each program or in one update program, I would still
want to recompile all of them any way to make sure no garbage? So as far
as minimizing compiles no big difference (one update program can help with
sharing pointers on the files, stopping record locks etc...)?

Thanks,

Jeff

Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."

Today's Topics:

1. Using one Update Program (Jeff Buening)
2. Re: Using one Update Program (Jon Paris)

----------------------------------------------------------------------

message: 1
date: Wed, 19 Jan 2011 09:37:50 -0500
from: Jeff Buening <JeffBuening@xxxxxxxxxxxxxxxxxxx>
subject: [COBOL400-L] Using one Update Program

Been running some test, to try to use one update program to help with
recompiles and maintenance. ?"UPDATEPRO" in my example is the update
program "PROGRAMA" calls "UPDATEPRO" for all I/O.... FILEA and FILEB are
Physical Files.

"PROGRAMA" Program info...

WORKING-STORAGE SECTION.

01 WS-FILEA-SAVE. COPY DD-TESTREC OF FILEA.

01 WS-FILEB-SAVE. COPY DD-RECTEST OF FILEB.

01 FILE-STATUS PIC X(2).

PROCEDURE SECTION.

CALL "UPDATEPRO" USING WS-FILEA-SAVE
WS-FILEB-SAVE
FILE-STATUS.

"UPDATEPRO" Program info...

SELECT FILEA etc...

FILE SECTION.

FD FILEA
01 FS-FILEA. COPY DD-TESTREC OF FILEA.

FD FILEB
01 FS-FILEB. COPY DD-RECTEST OF FILEB.

LINKAGE SECTION

01 LNK-FILEA. COPY DD-TESTREC OF FILEA.

01 LNK-FILEB. COPY DD-RECTEST OF FILEB.

01 LNK-FILE-STATUS PIC X(2).

PROCEDURE DIVISION USING
LNK-FILEA
LNK-FILEB
LNK-FILE-STATUS.

The read statments in program...

MOVE LNK-FILEA TO FS-FILEA.

READ FILEA
INVALID KEY
CONTINUE
END-READ.

MOVE FILEA-STATUS TO LNK-FILE-STATUS.

MOVE FS-FILEA TO LNK-FILEA.

The Rewrite statments in the program...

MOVE LNK-FILEA TO FS-FILEA.

REWRITE FS-FILEA
INVALID KEY
CONTINUE
END-READ.

MOVE FILEA-STATUS TO LNK-FILE-STATUS.

MOVE FS-FILEA TO LNK-FILEA.

So I added a field to the end of FILEA and just recompiled "UPDATEPRO".
Called "PROGRAMA" which calls "UPDATEPRO" for all I/O and Reads REWRITE
etc... And no problems.

Then DFU FILEA to put something in the new field on FILEA. Didn't
recompile. Called "PROGRAMA" which called "UPDATEPRO" and when the REWRITE
happened the file was still fine. Was not for sure if compiling "UPDATEPRO"
and not "PROGRAMA" would cause that new field in FILEA to be spaced out or
not with the 01 level MOVE in "UPDATEPRO"?

So I am thinking setting up like this will work in reducing compiles. Even
though I added a field to the FILEA, it didn't mess up the call between the
two programs or Read, Rewrite etc?
Am I assuming correctly or can anyone tell me I might be missing something
or could have problems with this?

Thanks,

Jeff

------------------------------

message: 2
date: Wed, 19 Jan 2011 10:19:24 -0500
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [COBOL400-L] Using one Update Program

Comments in-line.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

On Jan 19, 2011, at 9:37 AM, Jeff Buening wrote:

Was not for sure if compiling "UPDATEPRO"
and not "PROGRAMA" would cause that new field in FILEA to be spaced out

or

not with the 01 level MOVE in "UPDATEPRO"?

No - it won't be space filled - it will be garbage filled (the garbage may
of course if you are lucky be spaces!). All that is being passed to
UPDATEPRO is the pointer to the beginning of the field. Since that field is
longer in UPDATEPRO than PROGRAMA when you do the move you will pick up
whatever garbage happens to be beyond the end of the original storage.

So I am thinking setting up like this will work in reducing compiles.

Even

though I added a field to the FILEA, it didn't mess up the call between

the

two programs or Read, Rewrite etc?

The fact that nothing blew up doesn't mean it worked correctly.

Am I assuming correctly or can anyone tell me I might be missing

something

or could have problems with this?

You're getting garbage in the new fields whenever you write or update them.
That's rarely a good idea.

In my opinion the amount of time you might save in recompiles is likely to
disappear in a hurry when a weird bug is introduced by such coding
techniques.

Lying to the compiler is rarely a good idea. The only time I would even
consider this approach worthwhile is if the file is only being read and the
calling program doesn't need the data.

------------------------------

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.

End of COBOL400-L Digest, Vol 9, Issue 4
****************************************

************************************************************************************

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.