Re: inter subprogram in initial state, but only sometimes



"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:RPEsf.205172$ki.179803@xxxxxxxxxxx
> Frank Swarbrick wrote:
>> I know that if you put the "IS INITIAL" clause on the PROGRAM-ID
>> statement
>> it will reload all of working-storage every time the program is called.
>> I also know that the calling program can CANCEL the called program in
>> order
>> to remove it from memory, thus causing a "new" version of the program to
>> be
>> loaded the next time it is called.
>> But is there a way for the CALLED program to basically cancel itself once
>> it
>> is complete? In other words, I want the sub-program to sometimes be
>> entered
>> in it's last used state and sometimes in it's initial state. But only
>> the
>> sub-program itself needs to know when it wants to do one and when it
>> wants
>> to do the other. Of course it could pass something back to the caller
>> instructing the caller to cancel it, but the caller is not forced to obey
>> this.
>>
>> I don't actually have a need for this, but it did get me thinking...
>>
>
> Following up on Richard's comments made me have a re-look at above.
>
> What you didn't say of course is that you would like this feature to be
> COBOL 85 compliant - to Hell with OO ! :-). So just following up on your
> *desperate* attempt to get back to a thread on COBOL - some wild
> suggestions.
>
> First obviously ignore 'INITIAL STATE'
>
> Now send a flag to the Called Program telling it InitialState or
> StoredState and a return code Finished or NotFinished on the iterative
> cycle.
>
> 01 InitialValues.
> 05 a pic 9(?) value ?
> 05 b pic x(?) value ?
>
> How many fields do you want to hold ? Above could be all zeroes and
> spaces; alternatively they could hold initial values. Whatever; the above
> values would be used when receiving your InitialState flag.
>
> 01 StoredValues. -----> keep these in a file/table - see below
> 05 aa pic 9(?) value ?
> 05 bb pic x(?) value ?
>
> So having started with your InitialValues, and if the called program is
> not to be finalised, put values into StoredValues. Next call with the
> StoredState flag set True, and you use StoredValues instead.
>
> Want to get fancy using an OO buzzword - Persistent Objects - store the
> results of StoredValues in one Relative File record or a DB Table for
> retrieval on subsequent calls.
>
> Needless to say, the above is no big deal for OO. You can create one
> instance of a class, and providing you don't terminate it,
> (finalize/destroy/auto garbage collection), those Stored Values are
> *still* in Working Storage based on the last invoke which referenced and
> changed any of them. (Bear in mind any variables contained in a method
> Local-Storage are lost when you exit the method. Methods *always* start in
> an initial state).

Factory methods don't need to; they can be stateful, if required to be...
beware of generalizations like 'all' or 'always'...

I know you have dismissed Factory , but, as I stated in an earlier post, it
is useful.


>Further you could create additional 'sets' by having further instances of
>the same class which would all start in their InitialState, whether or not
>you were using zeroes or non zero values etc.
>

Obviously, for OO you could simply keep a pointer to an initial instance and
another pointer to an instance with its values reloaded as you describe. You
could then use either pointer to get the desired result.

I have done this to provide lookahead on a sequential file. Instantiate an
instance and read twice. Now instantiate another instance and read once. You
now have a reference to an instance whose "get Next" method returns record 3
and another reference to an instance whose "get Next" method returns record
2. Primary processing can be on the second object, but if you need to look
ahead within that processing, you simply invoke the first object. It works
quite well and there is no additional programming effort to cater for
lookahead.

Of course you could do the same with two selects and fds (if your
environment allows the same file to be connected and open more than once, in
the same app.), but where's the fun in that :-).

Pete.



.