Reformat ioc to IOC

marcelldls · web-flow · commit 9c343114d7b0 · 2023-11-14T09:33:45.000Z
diff --git a/docs/user/explanations/introduction.rst b/docs/user/explanations/introduction.rst
@@ -102,7 +102,7 @@ implementing these features:
 - View the current log
 - View historical logs (via graylog or other centralized logging system)
 - Connect to an IOC and interact with its shell
-- debug an ioc by starting a bash shell inside it's container
+- debug an IOC by starting a bash shell inside it's container
 
 
 Kubernetes Alternative
@@ -243,7 +243,7 @@ There are these types of CI:
       or other OCI registry
 
 :beamline definition source:
-    - prepares a helm chart from each ioc instance definition
+    - prepares a helm chart from each IOC instance definition
     - tests that the helm chart is deployable (but does not deploy it)
     - locally launches each IOC instance and loads its configuration to
       verify that the configuration is valid (no system tests because this
diff --git a/docs/user/reference/environment.rst b/docs/user/reference/environment.rst
@@ -58,7 +58,7 @@ Optional Variables
 - **EC_LOG_URL**: if you have a centralized logging service with a web UI then
   you can set this variable to the URL of the web UI. This will then be
   displayed when the command ``ec ioc log-history <ioc-name>`` is run. The
-  ioc name is added to the URL using ``{ioc-name}`` as a placeholder e.g.
+  IOC name is added to the URL using ``{ioc-name}`` as a placeholder e.g.
 
   - ``EC_LOG_URL='https://graylog2.diamond.ac.uk/search?rangetype=relative&fields``
     ``=message%2Csource&width=1489&highlightMessage=&relative=172800&q=pod_name%3A``
diff --git a/docs/user/reference/faq.rst b/docs/user/reference/faq.rst
@@ -12,7 +12,7 @@ engineering screens. TODO: more details will be added to a new section.
 Why have ioc-XXX repositories?
 ------------------------------
 Why not put the Dockerfile and image generating in the support module itself
-instead of creating a separate Generic ioc module for each image we
+instead of creating a separate Generic IOC module for each image we
 generate?
 
 Answers:
diff --git a/docs/user/tutorials/create_beamline.rst b/docs/user/tutorials/create_beamline.rst
@@ -104,7 +104,7 @@ Steps
 
     #. edit ``environment.sh``
 
-    #. change the name of the example ioc from ``iocs/blxxi-ea-ioc-01`` to
+    #. change the name of the example IOC from ``iocs/blxxi-ea-ioc-01`` to
        ``iocs/bl01t-ea-ioc-01``
 
     #. change the beamline name in the two bash scripts in the ``services``
diff --git a/docs/user/tutorials/deploy_example.rst b/docs/user/tutorials/deploy_example.rst
@@ -183,7 +183,7 @@ To stop / start  the example IOC try the following commands. Note that
 Monitoring and interacting with an IOC shell
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To attach to the ioc shell you can use the following command. HOWEVER, this
+To attach to the IOC shell you can use the following command. HOWEVER, this
 will attach you to nothing in the case of this example IOC as it has no
 shell. In the next tutorial we will use this command to interact with
 iocShell.
diff --git a/docs/user/tutorials/dev_container.rst b/docs/user/tutorials/dev_container.rst
@@ -188,7 +188,7 @@ See ``/epics/ioc-adsimdetector/ioc/iocApp/src/Makefile``
 
 You will note that the ``ioc`` folder is greyed out in the VSCode explorer. This
 is because it is in ``.gitignore`` and it is purely generated code. If you
-particularly needed to customize the contents of the ioc source tree then
+particularly needed to customize the contents of the IOC source tree then
 you can remove it from ``.gitignore`` and commit your changes to the repo. These
 changes would then always get loaded for every instance of the Generic IOC.
 
diff --git a/docs/user/tutorials/ibek.rst b/docs/user/tutorials/ibek.rst
@@ -42,20 +42,20 @@ ibek-support
   can be found and how to build it.
 - exists to avoid duplication of support module definitions in Generic IOCs
 - and to avoid working on multiple support modules while kicking off epics-containers
-- the ibek-support repo is added as a git-submodule to every Generic ioc
-  (ioc-xxx) repo and in this ensures that a rebuild of a Generic ioc will be
+- the ibek-support repo is added as a git-submodule to every Generic IOC
+  (ioc-xxx) repo and in this ensures that a rebuild of a Generic IOC will be
   with a consistent set of YAML files and install.sh files until a developer
   explicitly updates the submodule.
 
 How to work on ibek-support
 ---------------------------
 
-Building a new Generic ioc and making it compatible with ibek means creating
+Building a new Generic IOC and making it compatible with ibek means creating
 ibek support YAML for all of its dependent support modules
 (where they do not already exist)
 
-These steps assume you have a Generic ioc for ADUrl based on ioc_template as discussed in `generic_ioc`.
-Your Generic ioc has a default ioc instance used for testing.
+These steps assume you have a Generic IOC for ADUrl based on ioc_template as discussed in `generic_ioc`.
+Your Generic IOC has a default IOC instance used for testing.
 In ioc/config/st.cmd we have a default startup script for the example IOC.
 To work on ibek support we will remove this file and replace it with ``ioc.yaml``.
 We already have a git submodule for ibek-defs which we used for accessing patch files
@@ -64,7 +64,7 @@ during build, this will also be used for creating and editing support yaml files
 TODO: this will become a concrete example for walking through as a tutorial with ioc-adurl.
 
 NOTE: these steps are for building and testing the example IOC that comes with
-the Generic ioc template. This will break the system test and that would need
+the Generic IOC template. This will break the system test and that would need
 to be updated accordingly. To just work on ibek support files using an external
 ioc instance YAML file see `../how-to/ibek-support` (I probably need to combine
 these two pages into something coherent).
@@ -78,7 +78,7 @@ STEPS:
 - cd ..
 - add useful yaml definitions to ibek-defs/<a support module>/<a support module>.yaml
 - add some entities that use those definitions to ioc/config/ioc.yaml
-- TODO need to make dev launch mount ioc folder into the container - avoiding build step and giving us a tight inner dev loop
+- TODO need to make dev launch mount IOC folder into the container - avoiding build step and giving us a tight inner dev loop
   - (whereas dev ioc-launch mounts in the config of an IOC instance - MAYBE this is confusing or these commands need better names?)
 - ec dev build
 - ec dev launch
diff --git a/docs/user/tutorials/ioc_changes1.rst b/docs/user/tutorials/ioc_changes1.rst
@@ -87,7 +87,7 @@ If you see the value 1 then your change is working.
 
 Because of the symlink between ``/epics/ioc/config`` and
 ``/repos/bl01t/iocs/bl01t-ea-ioc-02/config`` the same files you are testing
-by launching the ioc inside of the devcontainer are also ready to be
+by launching the IOC inside of the devcontainer are also ready to be
 committed and pushed to the bl01t repo. i.e.:
 
 .. code-block:: bash
