In article <[log in to unmask]>,
  Jeff Kell <[log in to unmask]> wrote:
] Subject:      Re: Subprogram Question in COBOL
] >>On Fri, 24 Mar 1995 15:26:08 GMT Gary Peck said:
] >>>If anyone has any ideas on how I could speed up the performance, or If it
] >>>is even possible to open the database once in the subprogram and keep it
] >>>open for future processing your help would be greatly appreciated.
  and so forth.
 
I posted a response a week or so ago (naturally can't find it now) which
suggested putting the Cobol structure for the data base name (and file
number) in the main program and passing it as a parameter.
 
If I remember correctly, 1) the software was originally IBM main-frame, 2)
prior attempts to keep the data base open failed even though the
subroutine's working storage seemed to be maintained from call to call.
 
The reason I suggested moving the structure and DBOPEN/DBCLOSE calls to
the main program is because of a feature in Cobol 85 which is easy to
discount.  I'm working from the manual here, without a machine, and will
have to explain myself in classic terms, so please bear with me.
 
One method of coding IBM/MF Cobol involves using a variable in the CALL
statement.  Instead of CALL "XYZZY" USING . . . a programmer can (in Cobol
85) write CALL SUB-NAME USING . . . where SUB-NAME is an elementary item
of PIC X(6) (?) or  better, VALUE "XYZZY".  The method allows execution
time selection of libraries, but (as a side thought) can be helpful in
creating localized features.
 
Obviously the segmenter / linker cannot resolve these references - they
must be resolved at run-time.
 
I believe the mechanism used on classics is the LOADPROC intrinsic - it
loads the module named _with all the referenced modules_.  The Cobol
CANCEL statement (scraps the subroutine) would use UNLOADPROC.  I don't
know how it is implemented on the Spectrum machines.
 
I'm not sure where open files owned by a loaded procedure would be dealt
with, but I'm thinking that as part of the normal clean-up for exiting a
subroutine like this, there is a routine to close any open files - and
perhaps open data bases?  Checking the data base logs might confirm if a
DBCLOSE was being issued for you as the subroutine exits.
 
Gary - you may want to check and see if the code contains this type of
calling mechanism.  If so, this may be the cause of your problems.  If it
is, you can 1) change the calling mechanism to DYNAMIC and fix the CALL
statements, or 2) move data structures and DBOPEN/DBCLOSE calls to the
main program.
 
Or I could be totally up the wrong tree - would you let me know please?
 
--
Regards  --  Tony B. Shepherd  --  [log in to unmask]