Merge pull request #3495 from zowe/janan07-links-4

link fix

docs/extend/extend-apiml/custom-metadata.md

@@ -7,7 +7,7 @@ Additional metadata can be added to the instance information that is registered
     When this parameter is set to `true`, the Gateway allows encoded characters to be part of URL requests redirected through the Gateway. The default setting of `false` is the recommended setting. Change this setting to `true` only if you expect certain encoded characters in your application's requests.
 
     :::info Important
-    When the expected encoded character is an encoded slash or backslash (`%2F`, `%5C`), make sure the Gateway is also configured to allow encoded slashes. For  more information, see [Installing the Zowe runtime on z/OS](../../user-guide/install-zos.md).
+    When the expected encoded character is an encoded slash or backslash (`%2F`, `%5C`), make sure the Gateway is also configured to allow encoded slashes. For  more information, see [Zowe runtime](../../user-guide/install-zos.md#zowe-runtime) in Zowe server-side installation overview.
     :::
 
     :::note
@@ -53,7 +53,7 @@ Additional metadata can be added to the instance information that is registered
 * **customMetadata.apiml.corsEnabled**
 
     When this parameter is set to `true`, CORS handling by the Gateway is enabled on the service level for all service routes. 
-    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Cors configuration](../../user-guide/api-mediation/configuration-cors.md).
+    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md).
     Additional information can be found in this article about [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
 
     :::note
@@ -63,7 +63,7 @@ Additional metadata can be added to the instance information that is registered
 
 * **customMetadata.apiml.gatewayAuthEndpoint**
 
-  Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md)
+  Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md).
 
   :::note
   If you use the Spring enabler, use the following parameter name:
@@ -88,7 +88,7 @@ Additional metadata can be added to the instance information that is registered
   `apiml.service.customMetadata.apiml.corsAllowedOrigins`
   :::
 
-    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [CORS configuration](../../user-guide/api-mediation/configuration-cors.md).
+    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md).
 
  * **customMetadata.apiml.lb.type**
 
@@ -111,7 +111,7 @@ Additional metadata can be added to the instance information that is registered
 
       This value applies the Authentication load balancing schema. This is a sticky session functionality based on the ID of the user. The user ID is understood from the Zowe SSO token on the client's request. Requests without the token are routed in a round robin fashion. The user is first routed in a round robin fashion, and then the routed instance Id is cached. The instance information is used for subsequent requests to route the client to the cached target service instance. This session's default expiration time is 8 hours. After the session expires, the process initiates again.
 
-      In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributed load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache).
+      In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributing the load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache).
 * **customMetadata.apiml.lb.cacheRecordExpirationTimeInHours**  
 
    When the property `customMetadata.apiml.lb.type` is set to `authentication`, the user can also define the expiration time for the selected instance information that is cached. This property aims to prevent any discrepancy which might occur if the required target server is no longer available. The default value is 8 hours.   

docs/extend/extend-apiml/onboard-direct-eureka-call.md

@@ -257,8 +257,6 @@ The `serviceUrl` parameter provides a portion of the service instance URL path w
 **Note:** The routes configuration used for a direct REST call to register a service must also contain a prefix before the `gatewayUrl` and `serviceUrl`.
 This prefix is used to differentiate the routes. This prefix must be provided manually when _XML_ configuration is used.
 
-For more information about API ML routing, see [API Gateway Routing](https://github.com/zowe/api-layer/wiki/API-Gateway-Routing).
-
 #### Authentication parameters
 Authentication parameters are grouped under the prefix: `apiml.authentication`. When unspecified, the default values are used.
 

docs/extend/extend-apiml/onboard-micronaut-enabler.md

@@ -287,4 +287,4 @@ Create a `logback.xml` file in the `resources` folder and include the `applicati
 
 ## Validate successful registration
 
-After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by teh Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers.
+After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by the Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers.

docs/extend/extend-apiml/onboard-plain-java-enabler.md

@@ -536,7 +536,8 @@ where:
 
 ### Authentication parameters
 
-These parameters are not required. Default values are used when parameters are not specified. For more information, see [Authentication Parameters for Onboarding REST API Services](authentication-for-apiml-services.md/#authentication-parameters).
+These parameters are not required. Default values are used when parameters are not specified. For more information, see [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md#authentication-parameters).
+
 
 ### API Security
 
@@ -573,7 +574,8 @@ TLS/SSL configuration consists of the following parameters:
 
 * **keyStore**
 
-  This parameter specifies the keystore file used to store the private key. When using keyring, the value should be set to the SAF keyring location. For information about required certificates, see [Zowe API ML TLS requirements](zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements).
+  This parameter specifies the keystore file used to store the private key. When using keyring, the value should be set to the SAF keyring location. For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements).
+
 
   If you have an issue with loading the keystore file in your environment, try to provide the absolute path to the keystore file. The sample keystore file for local deployment is in [api-layer repository](https://github.com/zowe/api-layer/tree/master/keystore/localhost)
 
@@ -587,7 +589,7 @@ TLS/SSL configuration consists of the following parameters:
 
 * **trustStore**
 
-  This parameter specifies the truststore file used to keep other parties public keys and certificates. When using keyring, this value should be set to the SAF keyring location. For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements).
+  This parameter specifies the truststore file used to keep other parties public keys and certificates. When using keyring, this value should be set to the SAF keyring location. For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements).
 
   If you have an issue with loading the truststore file in your environment, try to provide the absolute path to the truststore file. The sample truststore file for local deployment is in [api-layer repository](https://github.com/zowe/api-layer/tree/master/keystore/localhost)
 
@@ -604,7 +606,9 @@ TLS/SSL configuration consists of the following parameters:
 ### SAF Keyring configuration
 
 You can choose to use SAF keyring instead of keystore and truststore for storing certificates.
-For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements). For information about running Java on z/OS with keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md) Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
+For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements). For information about running Java on z/OS with keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md#api-ml-saf-keyring).
+
+Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
 
 The following example shows enabler configuration with keyrings.
 
@@ -644,7 +648,7 @@ where:
 
 ### Custom Metadata
 
-For information about custom metadata, see the topic [Custom Metadata](custom-metadata).
+For information about custom metadata, see the topic [Custom Metadata](./custom-metadata.md).
     
 ##  Registering your service with API ML
 
@@ -814,7 +818,7 @@ public class ApiDiscoveryListener implements ServletContextListener {
 Once you are able to build and start your service successfully, you can use the option of validating that your service is registered correctly with the API ML Discovery Service.
 
 **Follow these steps:**
-  1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml)
+  1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml).
  
   2. Check that you can access your API service endpoints through the Gateway.
 

docs/extend/extend-apiml/onboard-spring-boot-enabler.md

@@ -314,7 +314,7 @@ A property notation provided in the format `-Dproperty.key=PROPERTY_VALUE` can b
 in any of the YAML configuration files.
 
 ### Authentication properties
-These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md/#authentication-parameters) for more details.
+These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md#authentication-parameters) for more details.
 
 ### API ML Onboarding Configuration Sample
 
@@ -440,7 +440,7 @@ logging:
 ### SAF Keyring configuration
 
 You can choose to use a SAF keyring instead of keystore and truststore for storing certificates.
-For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
+For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
 
 The following example shows enabler configuration with keyrings: 
 ```

docs/extend/extend-apiml/onboard-static-definition.md

@@ -350,13 +350,13 @@ additionalServiceMetadata:
             This value specifies that a service accepts PassTickets in the Authorization header of the HTTP requests using the basic authentication scheme.
             It is necessary to provide a service APPLID in the `apiml.authentication.applid` parameter.
 
-            **Tip:** For more information, see [Enabling PassTicket creation for API Services that accept PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets).
+            **Tip:** For more information, see [Authentication with PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets).
 
         * **safIdt**
 
             This value specifies that the application recognizes the SAF IDT scheme and fills the `X-SAF-Token` header with the token produced by the Saf IDT provider implementation.
 
-            For more information, see [SAF IDT provider](implement-new-saf-provider.md)
+            For more information, see [Implementing a new SAF IDT provider](implement-new-saf-provider.md).
 
         * **x509**
 

docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md

@@ -44,7 +44,7 @@ API ML uses the following authentication methods:
   - The client application passes the access JWT token to the API ML Gateway with subsequent requests for mainframe resources.
   - API ML federates the user identities and calls the requested resource with appropriate mainframe user credentials.
 
-For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md)
+For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md).
 
 ### Zowe API ML services
 

docs/user-guide/address-browser-requirements.md

@@ -7,10 +7,7 @@ Review the following browser requirements to avoid browser-specific issues when
 
 ## Zowe Desktop requirements (client PC)
 
-The Zowe Desktop is powered by the Application Framework which has server prereqs depending on where it is installed
-
-- [Zowe Application Framework on z/OS requirements](#zowe-application-framework-on-zos-requirements)
-- [Application Framework on Docker prerequisites](#docker-requirements-host)
+The Zowe Desktop is powered by the Application Framework which has server prereqs depending on where it is installed.
 
 The Zowe Desktop runs inside of a browser. No browser extensions or plugins are required.
 The Zowe Desktop supports Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge releases that are at most 1 year old, except when the newest release is older. For Firefox, both the regular and Extended Support Release (ESR) versions are supported under this rule.