When TCP refresh new code , after I change and compile the screen cobol.
ray
I change the SCREEN COBOL program and compile it successfully.
Questions are :
1.When the TCP get new version of SCREEN COBOL ?
2.Do I need to STOP ,START any TCP or TERM ?
Thanks !
Doug Miller
>Dear Garu,
> I change the SCREEN COBOL program and compile it successfully.
>Questions are :
>1.When the TCP get new version of SCREEN COBOL ?
Depends on your Pathway configuration. Have you checked the documentation?
>2.Do I need to STOP ,START any TCP or TERM ?
Depends on your Pathway configuration. Have you checked the documentation?
Keith Dick
If the compilation used as its output file the same Screen Cobol object library file that your Pathway system is using, then the program is immediately available to the running Pathway system. The next CALL of the program id from any Screen Cobol program running on any TERM will enter the newly-compiled program. TERMs that are currently running the program you compiled are not disturbed by the compile. The Screen Cobol object library holds multiple versions of the same Screen Cobol program, so different TERMs can be running different versions of the same program. You don't have to stop and restart the TERMs or the TCPs, unless the Screen Cobol program you compiled is the INITIAL program for the TERM, since such programs are entered just once, when you start the TERM. So in that case, you do have to stop and restart the TERMs. This also assumes that all of the TERMs and all the TCPs are using the same Screen Cobol object library. If you have several object libraries i
n use, then, of course, the newly-compiled program is only available to the TERMs that take their programs from the object library that you changed.
I have a vague memory that you can use SCUP to mark a Screen Cobol object library such that newly-compiled programs do not become the active version of the program, but I don't remember the details, and I didn't take the time to look it up in the manual. In any event, what I described in the first paragraph is certainly the normal case.
Now, compiling with the Screen Cobol object library of the production Pathway system as your target generally isn't a very good idea, for what should be obvious reasons. But if you are talking about compiling into the active library of a test Pathway system, that is fine, unless it interferes with your fellow developers. What I believe most sites do is compile into a test Pathway object library, test the program(s), then, when everything seems to be working, you can move the Screen Cobol object programs from the test library to the production library using the SCUP utility.
If you must update the production library with changes to multiple Screen Cobol programs, or with changes to a Screen Cobol program and the server(s) it uses, and those changes are incompatible with the previous versions of the programs, you must be careful of the timing of the changes if you do it while the application is live. That feature I mentioned in the second paragraph is a way to get Screen Cobol program changes ready, but not in use, and turn them on with one SCUP command. And if servers are involved in the changes, FREEZEing the servers, stopping them, changing the object files, restarting the servers, then changing the Screen Cobol requesters might be appropriate. It depends on the details of your application and its interdependencies.
Doug Miller
>If the compilation used as its output file the same Screen Cobol object library
> file that your Pathway system is using, then the program is immediately
> available to the running Pathway system. The next CALL of the program id from
> any Screen Cobol program running on any TERM will enter the newly-compiled
> program.
That is incorrect. If a TCP is configured with its CHECK-DIRECTORY attribute
set to OFF, existing terminal sessions under that TCP will never see the new
version of the program until a REFRESH-CODE command is executed against that
TCP.
[...]
>
>I have a vague memory that you can use SCUP to mark a Screen Cobol object
> library such that newly-compiled programs do not become the active version of
> the program, but I don't remember the details, and I didn't take the time to
> look it up in the manual.
This is probably the command you're thinking of:
SCUP ALTER SCOBOL-OBJECT <pobjfile>, ACCESS OFF
Keith Dick
> In article <btadnX1GgqzgyYTX...@giganews.com>, kd...@acm.org wrote:
>
>
>>If the compilation used as its output file the same Screen Cobol object library
>>file that your Pathway system is using, then the program is immediately
>>available to the running Pathway system. The next CALL of the program id from
>>any Screen Cobol program running on any TERM will enter the newly-compiled
>>program.
>
>
> That is incorrect. If a TCP is configured with its CHECK-DIRECTORY attribute
> set to OFF, existing terminal sessions under that TCP will never see the new
> version of the program until a REFRESH-CODE command is executed against that
> TCP.
>
If I remember correctly, CHECK-DIRECTORY can't entirely prevent use of a newly-introduced Scobol program. If the TCP doesn't have space to hold the object code of a newly-called Scobol program, it will discard the code of some unused Scobol programs, then if one of those discarded programs is called again, the latest copy will be fetched.
> [...]
>
>>I have a vague memory that you can use SCUP to mark a Screen Cobol object
>>library such that newly-compiled programs do not become the active version of
>>the program, but I don't remember the details, and I didn't take the time to
>>look it up in the manual.
>
>
> This is probably the command you're thinking of:
>
> SCUP ALTER SCOBOL-OBJECT <pobjfile>, ACCESS OFF
Yes, that seems familiar.
So there are at least two ways that keep newly-introduced Scobol programs from being used immediately. I wonder whether there are others that I've forgotten about.
Doug Miller
>Doug Miller wrote:
>> In article <btadnX1GgqzgyYTX...@giganews.com>, kd...@acm.org
> wrote:
>>
>>
>>>If the compilation used as its output file the same Screen Cobol object library
>>>file that your Pathway system is using, then the program is immediately
>>>available to the running Pathway system. The next CALL of the program id from
>>>any Screen Cobol program running on any TERM will enter the newly-compiled
>>>program.
>>
>>
>> That is incorrect. If a TCP is configured with its CHECK-DIRECTORY attribute
>> set to OFF, existing terminal sessions under that TCP will never see the new
>> version of the program until a REFRESH-CODE command is executed against that
>> TCP.
>>
>Thanks, Doug. That's a control I had forgotten about. I see now from looking
> at the documentation that what you say is true for TERMs that don't specify
> their own TCLPROG but rely on the one configured for their TCP. If a TCLPROG
> was specified in the TERM entry, apparently the CHECK-DIRECTORY setting has no
> effect for that TERM, and there seems not to be a way to specify that on a per
> TERM level.
Correct.
> A little odd, but since I think specifying TCLPROG at the TERM
> level is unusual, probably not terribly important.
"Unusual" perhaps understates the case. :-)
>
>If I remember correctly, CHECK-DIRECTORY can't entirely prevent use of a
> newly-introduced Scobol program. If the TCP doesn't have space to hold the
> object code of a newly-called Scobol program, it will discard the code of some
> unused Scobol programs, then if one of those discarded programs is called
> again, the latest copy will be fetched.
Correct.
>> [...]
>>
>>>I have a vague memory that you can use SCUP to mark a Screen Cobol object
>>>library such that newly-compiled programs do not become the active version of
>>>the program, but I don't remember the details, and I didn't take the time to
>>>look it up in the manual.
>>
>>
>> This is probably the command you're thinking of:
>>
>> SCUP ALTER SCOBOL-OBJECT <pobjfile>, ACCESS OFF
>
>Yes, that seems familiar.
>
>So there are at least two ways that keep newly-introduced Scobol programs from
> being used immediately. I wonder whether there are others that I've forgotten
> about.
The SCUP ALTER command can also explicitly specify an individual program or
program version, e.g.
ALTER SCOBOL-OBJECT <pobjfile> ( <programname> ), ACCESS OFF
ALTER SCOBOL-OBJECT <pobjfile> ( <programname> ( <versionnum> ) ), ACCESS OFF
Joe Bishop
> In article <FLOdnegDscro1ofX...@giganews.com>, kd...@acm.org wrote:
>> A little odd, but since I think specifying TCLPROG at the TERM
>> level is unusual, probably not terribly important.
>
> "Unusual" perhaps understates the case. :-)
The TCLPROG can also be defined for a PROGRAM. I've seen this used in
cases where two pobj filesets are desired (purely for management
purposes). One would hold general-use objects or application framework
code (usually the TCLPROG for the TCPs), and the other would hold
Pathway application specific code (defined for the TERMs and PROGRAMs).
Not all that unusual... :-)
Joe
ray
I find the answer from HP.
If your program is CALLED , REFRESH-CODE is workable.
If your program is root and no program calling it, Refresh-code is not
workable.
for example,
A ---> B --> C
B/C : refresh-code is workable .
A: you can not use refresh-code command
Doug Miller
As I noted in an earlier post, that's not the entire story. The setting of the
CHECK-DIRECTORY parameter also has an effect.