- fixed formatting in the submit man page

- added features to the release notes
   - RSMAP complex variables
   - per HOST complex variables
   - one-line JSON for accounting and reporting
   - per scope resource and queue requests

doc/markdown/man/man1/submit.include.md

@@ -1106,6 +1106,7 @@ The slave tasks shall run in the compute.q queue with a memory limit
 of 4G and one GPU.
 
 Using the **-scope** switch has a few constaints:
+
 * It cannot be used with sequential jobs.
 * Soft queue (**-q**) or resource requests (**-l**) are only allowed 
   in the global scope.

doc/markdown/manual/release-notes/03_major_enhancements.md

@@ -39,3 +39,204 @@ This will allow different processing components within `sge_qmaster` to use sepa
 enhancing the performance of the cluster in large environments.
 
 (Available in Open Cluster Scheduler and Gridware Cluster Scheduler)
+
+## New RSMAP (Resource Map) complex type
+
+Resource Maps are a new complex type that allows administrators to define a list of special resources which
+are available on a host, e.g. GPU devices, networking devices, lists of network ports, or other special resources.
+
+Resource Maps are defined in the complex definition as other consumable resources, e.g.:
+
+```
+#name          shortcut   type       relop requestable consumable default  urgency 
+#----------------------------------------------------------------------------------
+gpu            gpu        RSMAP      <=    YES         HOST       NONE     0
+```
+
+The capacity of RSMAPs can be defined on execution host level and on global level (global host) in the `complex_values`
+attribute.
+
+The RSMAP capacity consists of two parts: The number of available resources and a list of specific resources.
+
+Example for a GPU RSMAP:
+
+```
+$ qconf -se rocky-8-amd64-1
+hostname              rocky-8-amd64-1
+load_scaling          NONE
+complex_values        gpu=4(GPU1 GPU2 GPU3 GPU4)
+...
+```
+
+When a job is submitted the number of GPUs can be requested as resource request:  
+`qsub -l gpu=2 myjob.sh`    
+
+The job will be scheduled onto a host with at least 2 GPUs available.
+Which GPUs have been assigned to a job can be retrieved by the `qstat -j` command:
+
+```
+$ qstat -j 4
+==============================================================
+job_number:                 4
+...
+resource_map           1:   gpu=rocky-8-amd64-1=(GPU1 GPU2)
+```
+
+The job script can access the assigned GPUs via the environment variable `SGE_HGR_<complex_name>`, in this example
+`SGE_HGR_gpu`:
+```
+env | grep SGE_HGR
+SGE_HGR_gpu=GPU1 GPU2
+```
+
+In addition to listing the available resources explicitly (`GPU1 GPU2 GPU3 GPU4`), it is also possible to define
+ranges of resources.
+
+Examples for port numbers on a host:
+```
+$ qconf -sce port_number
+name        port_number
+shortcut    port
+type        RSMAP
+relop       <=
+requestable YES
+consumable  HOST
+default     NONE
+urgency     0
+
+$ qconf -se rocky-8-amd64-1 | grep complex_values
+complex_values        port_number=100(65000-65099)
+
+qrsh -l port_numbers=8 env | grep SGE_HGR
+SGE_HGR_port_number=65000 65001 65002 65003 65004 65005 65006 65007
+```
+
+## Per HOST complex variables
+
+The definition of complex variables contains the attribute `consumable` which could so far have the following values:
+
+- `NO`: The complex is not consumable.
+- `YES`: The complex is consumable and every task of a job consumes the requested amount of the resource.
+- `JOB`: The complex is consumable and the requested amount of the resource is consumed once by the job (in case 
+         of parallel jobs: by the master task).
+
+With the new `HOST` consumable type the requested amount of the resource is consumed once per host. Even if in case
+of parallel jobs multiple tasks are running on the same host, the requested amount of the resource is consumed only
+once. E.g. multiple tasks of a parallel job can share the same GPU.
+
+
+## One-line JSON format for accounting and reporting files
+
+The accounting and reporting files contain one line per record.
+The format of the records used to be a column-based format with a fixed number of columns,
+column separator was the colon `:`.
+
+The new acccounting and reporting file uses a one-line JSON format.
+This makes it easier to structurise and extend the accounting and reporting records with new fields in the future,
+and it makes it easier to parse the records with tools like `jq`, e.g.:
+
+```
+$ cat $SGE_ROOT/default/common/accounting.jsonl | jq  'select( .job_number == 4)'
+{
+  "job_number": 4,
+  "task_number": 0,
+  "start_time": 1725898198580794,
+  "end_time": 1725898298874079,
+  "owner": "joga",
+  "group": "joga",
+  "account": "sge",
+  "qname": "all.q",
+  "hostname": "rocky-8-amd64-1",
+  "department": "defaultdepartment",
+  "slots": 1,
+  "job_name": "sleep",
+  "priority": 0,
+  "submission_time": 1725898190122999,
+  "submit_cmd_line": "qsub -o /dev/null -j y -b y -l gpu=2 sleep 100",
+  "category": "-l gpu=2",
+  "failed": 0,
+  "exit_status": 0,
+  "usage": {
+    "rusage": {
+      "ru_wallclock": 100,
+      "ru_utime": 0.082395,
+      "ru_stime": 0.115703,
+      "ru_maxrss": 17428,
+      "ru_ixrss": 0,
+      "ru_ismrss": 0,
+      "ru_idrss": 0,
+      "ru_isrss": 0,
+      "ru_minflt": 9417,
+      "ru_majflt": 76,
+      "ru_nswap": 0,
+      "ru_inblock": 28544,
+      "ru_oublock": 8,
+      "ru_msgsnd": 0,
+      "ru_msgrcv": 0,
+      "ru_nsignals": 0,
+      "ru_nvcsw": 307,
+      "ru_nivcsw": 0
+    },
+    "usage": {
+      "wallclock": 100.90874,
+      "cpu": 0.198098,
+      "mem": 0.0020704269409179688,
+      "io": 0.0010261209681630135,
+      "iow": 0.0,
+      "maxvmem": 222384128.0,
+      "maxrss": 950272.0
+    }
+  }
+}
+```
+
+In case the old format is required, e.g. as it is parsed by some custom script,
+it can be enabled via the `reporting_params` configuration parameter.
+in the global configuration.  
+By default, the format is one-line JSON.  
+By adding the parameter `old_accounting=true` the old format is used for accounting.  
+By adding the parameter `old_reporting=true` the old format is used for reporting.
+
+The old format is still supported for backward compatibility, but it is recommended to use the new default JSON format,
+as extensions to the accounting and reporting records (e.g. more exact timestamps, the submission command line,
+additional usage values like maxrss) are only done in the new format.
+
+
+## Resource and queue requests per scope (global, master, slave) for parallel jobs
+
+In former product versions resource requests for parallel jobs were only possible on the global level.
+Resource requests for parallel jobs were applied to all tasks of the job, both master task (the job script)
+and slave tasks. It was possible to define specific queues for the master task with the `-masterq` option.
+
+Beginning with xxQS_NAMExx 9.0.0 it is possible to define resource request in 3 different scopes:
+* global requests are applied to all tasks
+* master requests are applied to the master task only
+* slave requests are applied to the slave tasks only
+
+The scope is selected by the `-scope` option of the submission command (qsub, qrsh, qlogin, qsh).  
+Per scope it is possible to do resource requests and queue requests.
+
+Example:
+
+Submit a 16 times parallel job where the master task requires 1G memory and the slave tasks require 2G memory each
+and a GPU.
+The master task shall run in the `io.q` queue and the slave tasks in the `compute.q` queue.
+
+```
+qsub -pe mpi 16 -scope master -q io.q -l memory=1G \
+     -scope slave -q compute.q -l memory=2G,gpu=1 job_script.sh
+```
+
+Using the -scope switch has the following constaints:
+
+* It cannot be used with sequential jobs.
+* Soft queue (-q) or resource requests (-l) are only allowed in the global scope.
+* Resource requests (-l option) for a specific variable can be done either in the global scope,
+  or in master and slave scope.
+* Per host resource requests on a specific variable can only be done in one scope,
+  either in global, in master or in slave scope.
+
+The `-scope master -q qname` replaces the old `-masterq qname` option. The `-masterq` option is still supported
+for backward compatibility, but it is recommended to use the new `-scope master` option.
+
+Resource requests per scope can also be modified by `qalter` and via JSV scripts.