Re: Called Module with File Access - where to Close

Just one note on a pretty "obscure" issue with allowing run-unit termination
 to
do the CLOSE. If your program does an EXPLICIT close, then you can check the
file-status and insure that it is "00".  If you let run-unit termination do 
this
(assuming IBM - where you say VSAM - and NOCMPR2 so you are '85 Standard), t
hen
it is true the run-unit termination will "close" the VSAM file - but *if* th
ere
is a problem you won't be able to do anything under program control.  It is
pretty rare (in my experience) that a VSAM close gets a non-zero FS - but al
l
I/O before is OK.  However, this is theoretically POSSIBLE.

--
Bill Klein
wmklein <at> ix.netcom.com
"jce" <defaultuser@hotmail.com> wrote in message
news:5n1De.9241$t43.7554@tornado.tampabay.rr.com...
> Just a style or philosophical question that has bugged me this w.  This
 is
> a two parter
>
> I have three separate execution units.
>
> Program A1 calls Program B repeatedly
> Program A2 calls Program B repeatedly
> Program A3 calls Program B repeatedly
>
> Program B will access a nice VSAM file looking up some key/alternate key d
ata.
>
> All three calling programs have no knowledge of what B does.
>
> I put in logic as such in Progam B:
>
> GET-VSAM-DATA.
>
> READ VSAM-FILE
>
> EVALUATE TRUE
> WHEN VSAM-STATUS-OK
>     DO STUFF
> .....
> WHEN VSAM-STATUS-NOT-OPEN
>      OPEN VSAM-FILE
> ....
>
> There is _never_ a call to CLOSE.  Is it acceptable IYHO to just allow the
> end-of-unit execution to clean this up?
> The file is always OPEN read only, and is SHR.  COBOL doesn't have a a
> finally{ } or a ~GET-VSAM {}  :-)
>
> I really don't want any of the calling programs to know about it but I'm
> considering create a BOPEN and a BCLOSE module that just has the VSAM-FILE
> definition as an external and opens and close.
>
> A1 calls BOPEN    {external VSAM definition and status}
> A1 calls B               {external VSAM definition and status}
> A1 calls BCLOSE  {external VSAM definition and status}
> A2 calls BOPEN    {external VSAM definition and status}
> A2 calls B               {external VSAM definition and status}
> A2 calls BCLOSE  {external VSAM definition and status}
> A3 calls BOPEN    {external VSAM definition and status}
> A3 calls B               {external VSAM definition and status}
> A3 calls BCLOSE  {external VSAM definition and status}
>
> This seems more "proper" but seems like extra code for no reason.  It also
> means that B is not a complete unit of function - it needs to be recognize
d as
> part of BOPEN, B, BCLOSE set....It would be nice if I could use ENTRY but 
this
> seems awful too.
>
> Anyone have comments on this stylistically? I think I'm happy leaving it a
s is
> but I get to give this code to  someone else at the end of the w and I 
have
> to have some level of pride when it comes to the code I provide !
>
>
> I'm also always tempted to use a GOTO - using Olivers tools, how could thi
s be
> implemented just as efficiently ? Assume for the sake of argument that thi
s
> thing has 300,000 reads on a customer machine each time it runs AND that I
'm
> too lazy to the OPEN and CLOSE as separate programs :-D
>
> GET-VSAM-DATA.
>
> READ VSAM-FILE.
>
> EVALUATE TRUE
> WHEN VSAM-STATUS-OK
>     DO STUFF
> WHEN VSAM-STATUS-NOT-FOUND
>     DO STUFF
> WHEN VSAM-STATUS-DUPLICATE-KEY
>     DO STUFF
> WHEN VSAM-STATUS-NOT-OPEN
>       OPEN VSAM-FILE
>       GOTO GET-VSAM-DATA
> END-EVALUATE.
>
>
> Many thanks for your consideration.
>
>
> JCE
>
>
>
>
>
>