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.
************************************************************************************
midrange.com
