Re: Using one Update Program (Jeff Buening) -- COBOL400-L

The problem with doing this is that the calling program's record definition
wasn't changed when the field was added to the file. You really should
recompile any program that references the file if you change that file's
layout otherwise you'll put garbage in any new fields and you'll have a real
mess if you delete any fields.

You could handle this differently though. One way would be to pass just the
fields you want updated in the record instead of the whole record. You
would, of course, need to include any key fields. Then your update program
could initialize added records appropriately and wouldn't be as likely to
mess up records if you delete fields.

Another way would be to validate the length of passed data to the record
length and handle mismatches appropriately.

Another thing to watch is record locks. Depending on how you end your
programs you might end up locking records from your job. If you call the
update program and it reads a record for update a 2nd call to the update
program that reads for update can fail since the first invocation of the
program locked the record.

Unless you're binding your programs with ILE you could also be adding a lot
of overhead to your application with calls to the update program.

I've worked with applications that did this and it can work well...but you
have to be very careful.

A MUCH better way to do I/O is to use SQL. SQL can remove your programs'
dependence on record layouts altogether.

Chuck Landress, PMP

On Wed, Jan 19, 2011 at 1:00 PM, <cobol400-l-request@xxxxxxxxxxxx> wrote:

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