| William M. Klein 2005-07-24, 8:17 pm |
| 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), then
it is true the run-unit termination will "close" the VSAM file - but *if* there
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 all
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 data.
>
> 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 recognized 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 as 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 this be
> implemented just as efficiently ? Assume for the sake of argument that this
> 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
>
>
>
>
>
>
|