Code templates in a push-to-client environment

Code templates are among the Eclipse preferences that can be exported to a remote system and distributed to clients by using the push-to-client feature. Before you create or edit code templates, be sure that you know which templates are local (created on your workstation) and which are remote (delivered to your workstation by using push-to-client). If you edit a remote template but do not give it a unique name, your edits might be overwritten when you connect to the remote system.

When you connect to a remote system that has the push-to-client feature enabled, any Eclipse preferences that have been exported from the model workspace are downloaded to your client workspace. Among the preferences that can be downloaded to a client workspace are COBOL, JCL, and PL/I code templatesis the JCL template. Developer for z/OS® can determine which templates originate in your client workspace (local templates) and which originate on the remote system (remote templates). Developer for z/OS preserves your local templates and updates the remote templates.

Developer for z/OS uses a combination of physical location and template name to determine which templates are local, which templates are remote, and how to merge them during a push-to-client operation. Developer for z/OS does not examine template content. It relies solely on template names to determine whether to replace a local template with a remote template.
Tip: When you create remote templates for downloading in a push-to-client environment, consider establishing a convention that indicates that the templates originate on a remote system. You might, for example, include the suffix "REMOTE" in the template name or add a description, such as, "Downloaded from sample.systemz.connection.com" or "Remote template; do not edit."
These rules govern how local and remote templates are merged:
  1. If a local template has the same name as a remote template, it is overwritten with the remote template.
  2. If multiple local templates have the same name as a remote template, the local templates are discarded and replaced with the remote template.
  3. The push-to-client operation can only add and replace templates on the client workspace. It cannot delete templates. If a template name is deleted from the remote system, but not from the client workspace, it remains in the workspace after the push-to-client operation.
  4. If a remote template is renamed on the client workspace after it is downloaded so that its name no longer matches any of the remote templates, it is not overwritten during a push-to-client operation.

Examples

The following examples describe several scenarios for merging local and remote templates during a push-to-client operation. Each example describes a list of template names in a client workspace, a list of template names on a remote system, and the list of merged templates on the workstation after a push-to-client operation.

In these examples, templates that have the same name are differentiated by prime (′), double-prime (′′), and triple-prime (′′′) symbols. The following example involves three templates named A: A is on the client workspace and A′ and A′′ are on the remote system. After a push-to-client operation, Template A is replaced by templates A′ and A′′. The user who is seeing the templates in the user interface, sees only that the client workspace now contains two templates named A. The content of these templates is replaced by the content of the templates on the remote system.
Local Templates Remote Templates Merged Templates
A A′, A′′ A′, A′′

Example 1: No local templates

No templates are defined on the client workspace. When a user connects to the remote system, remote templates A and B are downloaded to the client workspace.

Table 1. No Local Templates
Local Templates Remote Templates Merged Templates
[none defined] A, B A, B

Example 2: Merge

Template C is defined on the client workspace. Templates A and B are defined on the remote system. When a user connects to a remote system, templates A and B are added to the client workspace.

Table 2. Merge
Local Templates Remote Templates Merged Templates
C A, B A, B, C

Example 3: Merge and replace

Template A is defined on the client workspace. Templates A and B are defined on the remote system. When a user connects to the remote system:
  • Template A on the remote system replaces template A on the client workspace.
  • Template B is added to the client workspace.
Table 3. Merge and replace
Local Templates Remote Templates Merged Templates
A A′, B A′, B

Example 4: Merge and replace

Templates B and C are defined on the client workspace. Templates A and B are defined on the remote system. When a user connects to the remote system:
  • Template A is added to the client workspace.
  • Template B on the remote system replaces template B on the client workspace.
  • Template C remains on the client workspace.
Table 4. Merge and replace
Local Templates Remote Templates Merged Templates
B, C A, B′ A, B′, C

Example 5: Reconnecting to a remote system

No templates are defined on the client workspace. Templates A and B are defined on the remote system.
  1. The first time a user connects to the remote system, templates A and B are downloaded to the client workspace.
  2. The user renames template B to BB and creates templates C and D. On the remote system, template A is deleted and template C is created.
  3. The user disconnects from the remote system.
  4. When the user connects to the remote system again:
    • Template A remains on the client workspace
    • Template B is downloaded to the client workspace
    • Template BB remains on the client workspace
    • Template C is replaced on the client workspace
    • Template D remains on the client workspace
Table 5. Two connections
Connection Local Templates Remote Templates Merged Templates
First connection [none defined] A, B A, B
Second connection A, [B renamed to BB], C, D [A deleted], B, C′ A, B, BB, C′, D

Example 6: Reconnecting to a remote system; duplicate templates replaced

No templates are defined on the client workspace. One template named A and two templates named B are defined on the remote system.
  1. When a user connects to the remote system templates A, B, and B′ are downloaded to the client workspace.
  2. The user creates two additional templates named B and a template named C. On the remote system, template B′ is deleted, and templates B′′′′ and D are created.
  3. The user disconnects from the remote system.
  4. When the user connects to the remote system again:
    • Templates A, B, and B′′′′ replace templates A, B, B′, B′′, and B′′′ on the client workspace
    • Template C remains on the client workspace
    • Template D is added to the client workspace
Table 6. Two connections; duplicate templates replaced
Connection Local Templates Remote Templates Merged Templates
First connection [none defined] A, B, B′ A, B, B′
Second connection A, B, B′, B′′, B′′′, C A, B, [B′ deleted], B′′′′, D A, B, B′′′′, C, D
Remember: In the user interface, the user sees multiple templates named B. The prime symbols are included in these examples only to differentiate the templates that originate on the remote system from the templates that originate on the client workspace.

Example 7: Reconnecting to a remote system; deleted templates

No templates are defined on the client workspace. Templates A and B are defined on the remote system.
  1. When a user connects to the remote system, templates A and B are downloaded to the client workspace.
  2. The user deletes template A. On the remote system, template B is deleted.
  3. The user disconnects from the remote system.
  4. When the user connects to the remote system again:
    • Template A is downloaded to the client workspace
    • Template B remains on the client workspace
Table 7. Two connections; deleted templates
Connection Local Templates Remote Templates Merged Templates
First connection [none defined] A, B A, B
Second connection [A deleted], B A, [B deleted] A, B