Merge pull request #109508 from LauraBrenner/laura-manage-update

updates fixed

Author: Jak-MS

articles/batch/TOC.yml

@@ -69,6 +69,8 @@
   items:
   - name: Manage Batch accounts
     items:
+    - name: Manage your account
+    - href: batch-manage-account-basics.md
     - name: Manage Batch accounts with the portal
       href: batch-account-create-portal.md
     - name: Manage Batch accounts with Batch Management .NET

articles/batch/batch-cli-templates.md

@@ -28,7 +28,7 @@ are not developers. With only CLI commands, you can create a pool, upload input
 associated tasks, and download the resulting output data. No additional code is
 required. Run the CLI commands directly or integrate them into scripts.
 
-Batch templates build on the [existing Batch support in the Azure
+Batch templates build on the existing Batch support in the [Azure
 CLI](batch-cli-get-started.md#json-files-for-resource-creation) for JSON files to specify property values when creating pools,
 jobs, tasks, and other items. Batch templates add the following capabilities:
 
@@ -101,7 +101,7 @@ the following main concepts:
     -   Allow property values to be specified in a body section, with only
         parameter values needing to be supplied when the template is used. For
         example, the complete definition for a pool could be placed in the body
-        and only one parameter defined for pool id; only a pool ID string
+        and only one parameter defined for `poolId`; only a pool ID string
         therefore needs to be supplied to create a pool.
 
     -   The template body can be authored by someone with knowledge of Batch and

articles/batch/batch-manage-account-basics.md

@@ -12,7 +12,7 @@ ms.service: batch
 ms.workload: big-compute
 ms.tgt_pltfrm: na
 ms.topic: conceptual
-ms.date: 03/05/2020
+ms.date: 03/30/2020
 ms.author: labrenne
 ms.custom: H1Hack27Feb2017
 
@@ -30,13 +30,13 @@ You can run multiple Batch workloads in a single Batch account, or distribute yo
 
 The Batch account enables you to run large-scale parallel and high-performance computing (HPC) batch jobs efficiently in Azure. Within the account you manage:
 
-- the applications you are running
+- The applications you are running
 
-- the allocation of pools and nodes within pools
+- The allocation of pools and nodes within pools
 
-- the number and types of tasks 
+- The number and types of tasks 
 
-- the input and output of data. You don't need to install additional software to manage tasks.
+- The input and output of data. You don't need to install additional software to manage tasks.
 
 - When you create the Batch account, you are asked to assign a name to it. This name is its ID and once assigned cannot be changed.
 

articles/batch/best-practices.md

@@ -81,7 +81,7 @@ A job is a container designed to contain hundreds, thousands, or even millions o
     Do not design a Batch solution that requires thousands simultaneously of active jobs. There is no quota for tasks, so executing as many tasks under as few jobs as possible efficiently uses your [job and job schedule quotas](batch-quota-limit.md#resource-quotas).
 
 - **Job lifetime**  
-    A Batch job has an indefinite lifetime until it's deleted from the system. A job’s state designates whether it can accept more tasks for scheduling or not. A job does not automatically move to completed state unless explicitly terminated. This can be automatically triggered through the [onAllTasksComplete](https://docs.microsoft.com/dotnet/api/microsoft.azure.batch.common.onalltaskscomplete?view=azure-dotnet) property or [maxWallClockTime](https://docs.microsoft.com/rest/api/batchservice/job/add#jobconstraints).
+    A Batch job has an indefinite lifetime until it's deleted from the system. A job's state designates whether it can accept more tasks for scheduling or not. A job does not automatically move to completed state unless explicitly terminated. This can be automatically triggered through the [onAllTasksComplete](https://docs.microsoft.com/dotnet/api/microsoft.azure.batch.common.onalltaskscomplete?view=azure-dotnet) property or [maxWallClockTime](https://docs.microsoft.com/rest/api/batchservice/job/add#jobconstraints).
 
 There is a default [active job and job schedule quota](batch-quota-limit.md#resource-quotas). Jobs and job schedules in completed state do not count towards this quota.
 
@@ -111,12 +111,12 @@ Tasks are individual units of work that comprise a job. Tasks are submitted by t
 
 ### Designing for retries and re-execution
 
-Tasks can be automatically retried by Batch. There are two types of retries: user-controlled and internal. User-controlled retries are specified by the task’s [maxTaskRetryCount](https://docs.microsoft.com/dotnet/api/microsoft.azure.batch.taskconstraints.maxtaskretrycount?view=azure-dotnet). When a program specified in the task exits with a non-zero exit code, the task is retried up to the value of the `maxTaskRetryCount`.
+Tasks can be automatically retried by Batch. There are two types of retries: user-controlled and internal. User-controlled retries are specified by the task's [maxTaskRetryCount](https://docs.microsoft.com/dotnet/api/microsoft.azure.batch.taskconstraints.maxtaskretrycount?view=azure-dotnet). When a program specified in the task exits with a non-zero exit code, the task is retried up to the value of the `maxTaskRetryCount`.
 
 Although rare, a task can be retried internally due to failures on the compute node, such as not being able to update internal state or a failure on the node while the task is running. The task will be retried on the same compute node, if possible, up to an internal limit before giving up on the task and deferring the task to be rescheduled by Batch, potentially on a different compute node.
 
 - **Build durable tasks**  
-    Tasks should be designed to withstand failure and accommodate retry. This is especially important for long running tasks. To do this, ensure tasks generate the same, single result even if they are run more than once. One way to achieve this is to make your tasks “goal seeking”. Another way is to make sure your tasks are idempotent (tasks will have the same outcome no matter how many times they are run).
+    Tasks should be designed to withstand failure and accommodate retry. This is especially important for long running tasks. To do this, ensure tasks generate the same, single result even if they are run more than once. One way to achieve this is to make your tasks "goal seeking". Another way is to make sure your tasks are idempotent (tasks will have the same outcome no matter how many times they are run).
 
     A common example is a task to copy files to a compute node. A simple approach is a task that copies all the specified files every time it runs, which is inefficient and isn't built to withstand failure. Instead, create a task to ensure the files are on the compute node; a task that doesn't recopy files that are already present. In this way, the task picks up where it left off if it was interrupted.