Replace ficticious domain names with example.com

jt-nti · jt-nti · commit d0092b07476e · 2025-10-02T09:47:16.000+01:00
example.com is reserved for documentation purposes and avoids any
potential problems that might occur if ficticious names are actually
registered

Signed-off-by: James Taylor &lt;jamest@uk.ibm.com&gt;
diff --git a/README.md b/README.md
@@ -28,7 +28,7 @@ For more information about contributing to the Zowe documentation, see:
 
 Zowe requires the use of the Developer’s Certificate of Origin 1.1 (DCO). Every commit to this repo and other Zowe repos should be signed off using DCO. Otherwise, the PR could not be merged.
 
-To sign off a commit, add a Signed-off-by line to your commit message. For example, `Signed-off-by: John Doe john.doe@hisdomain.com`.
+To sign off a commit, add a Signed-off-by line to your commit message. For example, `Signed-off-by: John Doe john.doe@example.com`.
 
 #### Tools for automatic DCO signoff
 
diff --git a/docs/appendix/zowe-yaml-configuration.md b/docs/appendix/zowe-yaml-configuration.md
@@ -198,8 +198,8 @@ The high-level configuration `zowe` supports these definitions:
    ```yaml
    zowe:
     externalDomains:
-    - external.my-company.com
-    - additional-dvipa-domain.my-company.com
+    - external.example.com
+    - additional-dvipa-domain.example.com
    ```
  In Kubernetes deployment, this value is the domain name you will use to access your Zowe running in a Kubernetes cluster.
 - **zowe.externalPort**  
@@ -314,10 +314,10 @@ zowe:
           ca:
           user: IZUSVR
       san:
-        - zos.my-company.com
-        - internal-lpar1.zos.my-company.com
-        - internal-lpar2.zos.my-company.com
-        - internal-lpar3.zos.my-company.com
+        - zos.example.com
+        - internal-lpar1.zos.example.com
+        - internal-lpar2.zos.example.com
+        - internal-lpar3.zos.example.com
       importCertificateAuthorities:
         - 
     vsam:
diff --git a/docs/appendix/zwe_server_command_reference/zwe/init/zwe-init-certificate.md b/docs/appendix/zwe_server_command_reference/zwe/init/zwe-init-certificate.md
@@ -64,17 +64,17 @@ zowe:
           ca:
           user: IZUSVR
       san:
-        - zos.my-company.com
-        - internal-lpar1.zos.my-company.com
-        - internal-lpar2.zos.my-company.com
-        - internal-lpar3.zos.my-company.com
+        - zos.example.com
+        - internal-lpar1.zos.example.com
+        - internal-lpar2.zos.example.com
+        - internal-lpar3.zos.example.com
       importCertificateAuthorities:
         - 
   externalDomains:
-   - zos.my-company.com
+   - zos.example.com
   verifyCertificates: STRICT
 zOSMF:
-  host: zosmf.my-company.com
+  host: zosmf.example.com
   port: 443
 ```
 
diff --git a/docs/contribute/roadmap-contribute.md b/docs/contribute/roadmap-contribute.md
@@ -36,7 +36,7 @@ Before submitting a Pull Request, review the general Zowe [Pull Request Guidelin
 
 All Zowe commits need to be signed by using the [Developer’s Certificate of Origin 1.1 (DCO)](https://developercertificate.org/), which is the same mechanism that the Linux® Kernel and many other communities use to manage code contributions. You need to add a `Signed-off-by` line as a part of the commit message. Here is an example `Signed-off-by` line, which indicates that the submitter accepts the DCO:
 
-```Signed-off-by: John Doe <john.doe@hisdomain.com>```
+```Signed-off-by: John Doe <john.doe@example.com>```
 
 You can find more information about DCO signoff in the [zac repo](https://github.com/zowe/zac/blob/master/CONTRIBUTING.md). 
 
diff --git a/docs/extend/component-registries.md b/docs/extend/component-registries.md
@@ -32,7 +32,7 @@ If the package is found in the registry, that extension and all of its dependenc
 
 The above example omits the registry configuration information, so the values default to what is containted within the zowe.yaml
 If they were explicitly provided instead, the command may look like
-`zwe components install -o my-zowe-extension --config zowe.yaml --handler npm --registry https://my-on-prem-registry.company.com/npm`
+`zwe components install -o my-zowe-extension --config zowe.yaml --handler npm --registry https://my-on-prem-registry.example.com/npm`
 
 ### Upgrading an extension
 
diff --git a/docs/extend/server-schemas.md b/docs/extend/server-schemas.md
@@ -25,7 +25,7 @@ Below is an example manifest and schema for a Component named "component1". The
 
 ```
 name: component1
-id: com.abcdef.component1
+id: com.example.abcdef.component1
 title: component1
 description: An example component with a simple configuration.
 license: ABCDEF Company License
@@ -41,7 +41,7 @@ Below is an example of the "schema.json" file referenced above. In it, we have 1
 ```
 {
   "$schema": "https://json-schema.org/draft/2019-09/schema",
-  "$id": "https://abcdef.com/schemas/v2/component1",
+  "$id": "https://abcdef.example.com/schemas/v2/component1",
   "allOf": [
     { "$ref": "https://zowe.org/schemas/v2/server-base" },
     { "type": "object",
diff --git a/docs/troubleshoot/app-framework/app-troubleshoot.md b/docs/troubleshoot/app-framework/app-troubleshoot.md
@@ -221,7 +221,7 @@ An application plug-in is not appearing in the Zowe Desktop.
 **Solution:**   
 To check whether the plug-in loaded successfully, enter the following URL in a browser to display all successfully loaded Zowe plug-ins:
 
-`https://my.mainframe.com:7556/plugins?type=application`
+`https://mymainframe.example.com:7556/plugins?type=application`
 
 You can also search the [node server logs](app-mustgather.md) for the plug-in identifier, for example `org.zowe.sample.app`. If the plug-in loaded successfully, you will find the following message:
 ```
diff --git a/docs/user-guide/api-mediation/configuration-customizing-the-api-catalog-ui.md b/docs/user-guide/api-mediation/configuration-customizing-the-api-catalog-ui.md
@@ -29,7 +29,7 @@ It is possible to customize the logotype and selected style options directly in
    Specifies the HTML color of the main text across the API Catalog
    - **docLink**  
    Specifies a custom link to be displayed in the header. Use this property to refer to applicable documentation. The format is `<link_name>|<link_url>`  
-       **Example:** `docLink: Custom Documentation|https://somedoc.com`
+       **Example:** `docLink: Custom Documentation|https://somedoc.example.com`
 
      Follow this example to define this parameter globally.
 
@@ -46,7 +46,7 @@ It is possible to customize the logotype and selected style options directly in
                        headerColor: grey
                        backgroundColor: #FFFFFF
                        textColor: blue
-                       docLink: Custom Documentation|https://somedoc.com
+                       docLink: Custom Documentation|https://somedoc.example.com
        ```
   
       Properties in the example that are not set default to Zowe API Catalog css values.
diff --git a/docs/user-guide/certificate-configuration-scenarios.md b/docs/user-guide/certificate-configuration-scenarios.md
@@ -101,7 +101,7 @@ Use this procedure to configure the `zowe.setup.certificate` section in your yam
     ```
     san:
         sample domain name
-        - dvipa.my-company.com
+        - dvipa.example.com
         sample IP address
         - 12.34.56.78
      ```
@@ -135,7 +135,7 @@ For more information, see this article in [IBM Support](https://www.ibm.com/supp
          country: "CZ"
        validity: 3650
        san:
-         - system.my-company.com
+         - system.example.com
          - 12.34.56.78
 ```
 Your yaml file is now configured to enable Zowe to use generated PKCS12 certificates.
@@ -261,7 +261,7 @@ Use this procedure to configure the `zowe.setup.certificate` section in your yam
 this field is not defined, the `zwe init` command uses the value `zowe.externalDomains`.  
     ```
     san:
-      - dvipa.my-company.com
+      - dvipa.example.com
       - 12.34.56.78
     ```
 :::note
@@ -290,7 +290,7 @@ Due to the limitation of the `RACDCERT` command, this field should contain exact
        country: "CZ"
      validity: 3650
      san:
-       - system.my-company.com
+       - system.example.com
        - 12.34.56.78
    ```
 Your yaml file is now configured to enable Zowe to use a z/OS keyring-based keystore with Zowe generated certificates.
diff --git a/docs/user-guide/cli-db2plugin.md b/docs/user-guide/cli-db2plugin.md
@@ -177,7 +177,7 @@ You can get your connection information by either:
             LOCATION  DSNV123E                  
             LU        GBIBMIYA.IYCYZDBE         
             GENERICLU -NONE                     
-            DOMAIN    domain.host.acme.com  
+            DOMAIN    domain.host.example.com  
             TCPPORT   40100                     
             SECPORT   30100
     ```
diff --git a/docs/user-guide/cli-using-creating-global-user-profiles.md b/docs/user-guide/cli-using-creating-global-user-profiles.md
@@ -70,7 +70,7 @@ Open the `~/.zowe/zowe.config.json` file in a text editor or IDE on your compute
         "global_base": {
             "type": "base",
             "properties": {
-                "host": "example1.com"
+                "host": "example.com"
             },
             "secure": [
                 "user",
diff --git a/docs/user-guide/cli-using-creating-profiles.md b/docs/user-guide/cli-using-creating-profiles.md
@@ -18,7 +18,7 @@ In the following configuration, nested profiles (highlighted in the example) use
     "profiles": {
         "lpar1": {
             "properties": {
-                "host": "example1.com"
+                "host": "lpar1.example.com"
             },
             "profiles": {
                 // highlight-start
@@ -47,7 +47,7 @@ In the following configuration, nested profiles (highlighted in the example) use
         },
         "lpar2": {
             "properties": {
-                "host": "example2.com"
+                "host": "lpar2.example.com"
             },
             "profiles": {
                 // highlight-start
@@ -90,7 +90,7 @@ In the following configuration, profiles are highlighted to show they are nested
     "profiles": {
         "lpar1": {
             "properties": {
-                "host": "example1.com"
+                "host": "lpar1.example.com"
             },
             "profiles": {
                 // highlight-start
@@ -123,7 +123,7 @@ In the following configuration, profiles are highlighted to show they are nested
         },
         "lpar2": {
             "properties": {
-                "host": "example2.com"
+                "host": "lpar2.example.com"
             },
             "profiles": {
                // highlight-start
@@ -280,7 +280,7 @@ To authenticate to a specific API ML gateway from this configuration, issue the
     "profiles": {
         "lpar1": {
             "properties": {
-                "host": "example1.com",
+                "host": "lpar1.example.com",
                 "port": 7554,
                 "tokenType": "apimlAuthenticationToken"
             },
@@ -318,7 +318,7 @@ To authenticate to a specific API ML gateway from this configuration, issue the
         },
         "lpar2": {
             "properties": {
-                "host": "example2.com",
+                "host": "lpar2.example.com",
                 "port": 7554,
                 "rejectUnauthorized": false,
                 "tokenType": "apimlAuthenticationToken"
@@ -366,7 +366,7 @@ Use the `--base-profile` option on Zowe CLI commands to select a base profile th
         },
         "lpar1": {
             "properties": {
-                "host": "example1.com",
+                "host": "lpar1.example.com",
                 "port": 7554,
                 "tokenType": "apimlAuthenticationToken"
             },
@@ -376,7 +376,7 @@ Use the `--base-profile` option on Zowe CLI commands to select a base profile th
         },
         "lpar2": {
             "properties": {
-                "host": "example2.com",
+                "host": "lpar2.example.com",
                 "port": 7554,
                 "tokenType": "apimlAuthenticationToken"
             },
diff --git a/docs/user-guide/cli-using-editing-team-configuration.md b/docs/user-guide/cli-using-editing-team-configuration.md
@@ -27,7 +27,7 @@ To define additional mainframe services and other profiles in an existing global
             "global_base": {
                 "type": "base",
                 "properties": {
-                    "host": "example1.com"
+                    "host": "example.com"
                 },
                 "secure": [
                     "user",
diff --git a/docs/user-guide/generate-certificates.md b/docs/user-guide/generate-certificates.md
@@ -66,19 +66,19 @@ zowe:
         country: ""
       validity: 3650
       san:
-        - dvipa.my-company.com
+        - dvipa.example.com
         - 12.34.56.78
 ```
 
 :::tip
-To get the san IP address, run `ping dvipa.my-company.com` in your terminal. 
+To get the san IP address, run `ping dvipa.example.com` in your terminal. 
 :::
 
 ### Run the command to generate a PKCS12 keystore
 
 After you configure the `zowe.yaml`, use the following procedure to generate the PKCS12 certificate.
 
-1. Log in to your system. In this example, run `ssh dvipa.my-company.com` with your password. 
+1. Log in to your system. In this example, run `ssh dvipa.example.com` with your password. 
 
 2. Run the following command in the directory with this `zowe.yaml` in the terminal to generate the certificate and update the configuration values in the `zowe.yaml` file.
 
@@ -205,7 +205,7 @@ zowe:
         country: ""
       validity: 3650
       san:
-        - dvipa.my-company.com
+        - dvipa.example.com
         - 12.34.56.78
 ```
 
@@ -220,7 +220,7 @@ zowe:
 
 After you configure the `zowe.yaml`, use the following procedure to generate a JCERACFKS certificate.
 
-1. Log in to your system. In this example, run `ssh dvipa.my-company.com` with your password.
+1. Log in to your system. In this example, run `ssh dvipa.example.com` with your password.
 
 2. Run the following command in the directory with this `zowe.yaml` in terminal to generate the certificate and update the configuration values in `zowe.yaml`.
 
diff --git a/docs/user-guide/install-zowe-server-install-wizard.md b/docs/user-guide/install-zowe-server-install-wizard.md
@@ -96,7 +96,7 @@ This option allows you to follow the installation steps without running the inst
 
   Field name| Description                
   ---|---
-  Host      |Value for the target z/OS system for Zowe Installation. For example, `mainframe.yourcompany.com`
+  Host      |Value for the target z/OS system for Zowe Installation. For example, `mainframe.example.com`
   FTP Port  |The FTP Port number for internal use. The default port is 21. If not specified, the Wizard uses the default port.
   User Name |Your z/OS username.
   Password  |Your z/OS password.
diff --git a/docs/user-guide/k8s-config.md b/docs/user-guide/k8s-config.md
@@ -119,7 +119,7 @@ Next, on z/OS, run the following command:
 
 ```
 cd <runtime-dir> 
-./bin/zwe migrate for kubernetes --config /path/to/my/zowe.yaml --domains "my-k8s-cluster.company.com"
+./bin/zwe migrate for kubernetes --config /path/to/my/zowe.yaml --domains "my-k8s-cluster.example.com"
 ``` 
 
 For more detailed explaination of zwe migrate command parameters, see [zwe migrate for kubernetes](../appendix/zwe_server_command_reference/zwe/migrate/for/zwe-migrate-for-kubernetes.md).
diff --git a/docs/user-guide/start-zowe-zos.md b/docs/user-guide/start-zowe-zos.md
@@ -86,7 +86,7 @@ zwe start --config /path/to/my/zowe.yaml --ha-instance hainst2
 ```yaml
 haInstances:
   hainst2:
-    hostname: lpar2-domain.com
+    hostname: lpar2.example.com
     sysname: LPAR2
 ```
 
