In z/OS, I can define a user EMP (Event Monitor Point) in the CICS MCT (Monitor Control Table). For example, one EMP can start a CPU clock/timer and another EMP can halt the CPU clock. I can then "execute" each EMP from my COBOL program during a TASK that runs the program. Execution of EMP "no.1" will start the clock and execution of EMP "no.2" will halt the clock.
I know that the eventual value of the CPU clock will be saved as part of the SMF 110 record that is written after completion of the TASK.
My question is, can the current value of the CPU clock be retrieved in the COBOL program while the TASK is still in execution?
If so, which CICS statement will do this? and into which structure/layout and field will the clock be retrieved?
The reason I wish to know is because I want to measure the CPU time that it takes for a certain process to be performed by the program. The same process may be performed a number of times in one TASK and I want to use the same CPU clock to measure each time that the process is performed.
Thanks very much,
Danny
EXEC CICS COLLECT STATISTICS MONITOR(EIBTASKN) SET (ADDRESS OF DFHMNTDS) can be used to retrieve a running task monitoring fields - as Danny pointed out in comment below.
DFHMCT TYPE=EMP macro with PERFORM=DELIVER may be fit for your purpose. It causes the Performance class data accumulated for this task up to this point delivered to the monitoring buffers. See CICS document:
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/reference/resources/macros/mct/emp.html
If you are on CICS TS V5.4 or later, you might consider to separate out the process that runs repeatedly to a transaction. Then use 'EXEC CICS RUN TRANSID CHILD' to start the transaction from the current COBOL program/task, which will start the process as a child task with the CPU being measured for it. You can get the response back from the child task using 'EXEC CICS FETCH CHILD'.
For details of using the two APIs please see articles in CICS Developer Center: https://developer.ibm.com/cics/category/asynchronous-api/
Thanks & kind regards,
Jenny (CICS development, IBM Hursley Lab)
Related
I have a batch job and a CICS transaction that use the same db2 tables. Both run at regular intervals and the batch job abends once in a while due to contention with the shared DB2 tables.
Is there a way to schedule the job in CA7 (job scheduling tool) to prevent it from running when the transaction is active?
Disable the CICS transaction before starting the batch job, re-enable it when the batch job ends.
Modify the batch job to use commit intervals, similar to this answer.
Checking to see if the CICS transaction is active is unlikely to behave as you wish. It may be inactive when you check, then you start your batch job, then the CICS transaction becomes active.
Update #1
Though you don't specify, I'm getting the impression this is a long-running CICS transaction and not the normal OLTP-style transaction that finishes in less than 0.10 seconds of clock time.
If this is the case, then creating a batch program that uses the EXCI to execute a CICS program that uses the CICS SPI INQUIRE TASKLIST to locate your transaction may be the way to proceed. If you've got CA-DADs PLUS then you might be able to do this with that product instead of writing programs.
Please refer to the below thread to see whether it helps you in overcoming the issue.
https://ibmmainframes.com/about12949.html
Regards,
Anbu.
We have a job on our SQL database that runs periodically forever.
During predefined maintenance periods, we would like to have this job stop for a set time (say 12 hours) and then restart the regular periodic schedule.
We've tried using a separate job that disables it a the predefined time and a second one that enables it. This works but is not very neat.
Is there a better way to do this that only involves the job itself?
Make a "maintenance schedule" table in some service database or MSDB (StartDate, EndDate, Description, etc.). Let the first step of your job check if current datetime within maintenance period. If so, just do nothing.
If a session or transaction is associated with the maintenance process then you could use an application lock to have the regular job wait, or terminate, if it attempts to run while the maintenance is in process.
Using a locking mechanism allows finer control over the processes, e.g. the regular job can release and reacquire the lock between steps and wait (or terminate) if the maintenance process has started. Alternatively, the maintenance process could wait for the regular job to terminate (or reach a suitable checkpoint) before proceeding.
See sp_getapplock for additional information.
Currently, I am reading about Schedulers and scheduling algorithms.
I am really confused with short-term scheduler and dispatcher.
At some places, it is written that they are same. At some places, it is written that their jobs are different.
From whatever I read I concluded that - "Scheduling" of the scheduler is caused by the code associated with a hardware interrupt, or code associated with a system call. With this a mode switch from user mode to kernel mode took place. Then short-term scheduler selects a process from a queue of the available process to give it control of the CPU. The task of short-term scheduler ends here.
Now dispatcher comes into play. The dispatcher is the module that gives control of the CPU to the process selected by the short-term scheduler. This function involves the following: -Switching context -Switching to user mode -Jumping to the proper location in the user program to restart that program.
Is my understanding correct?
Suppose Process A is preempted and process B is scheduled next. What happened during the context switch ? How context data of Process
A, scheduler, dispatcher, Process B is saved and restored?
The various divisions of the process switching steps are system dependent. Operating system books like to make these steps complicated and divide the into multiple steps.
There are really only two steps:
1. pick a the new process.
2. Switch to the new process.
That last step is very simple; so simple that it is probably not worthy of being called a separate step.
Most CPUs define a structure that is usually called the Process Context Block (PBC). The PCB has a slot for every register that defines the state of the process. Switching processes can be as simple as:
SAVEPCTX pcb_address_of_current_process ; Save the state of the running process
LOADPCTX pcb_address_of_new_process ; Load the state of the other process.
REI
Some processors require more steps, like having to save floating point registers separately.
Recently, I have been reading about Operating Systems, and this bugs me a lot.
How is it really possible for one process to manage other process.
Basically a CPU simply executes instructions, after executing one instruction, then it executes the instruction at address pointed by IP and increments the IP.
Let me elaborate my doubt with an example. Lets say I have an User process (or simply a process) which is being executed by CPU. Lets say, it has 'n' instruction and currently executing 'i'th instruction. IP points to (i+1)th instruction.
So, at this point how can all other OS processes like Scheduler, dispatcher etc... comes into play, Since CPU is already executing another process.
One solution (Just a guess), I could think of is , the use of Interrupts and Interrupt Service Routines.
But its only a guess.
PS: I searched and couldn't find any satisfying answer.
With the help of the hardware, ticks causes the CPU to execute operating system code. This code checks the system state and the time that has elapsed since the beginning of this process execution. At this point, the operating system can decide to schedule a different process. All it has to do is save the current state of the running process with the process that is about to start running. (basically changing the content of the registers and saving the registers state before changing to the new process).
Eventually, the CPU is taken away even if the process doesn't want to yield it.
To address your concern, there are no operating system processes in the way you think... it isn't like there are OS processes in the queue waiting among other processes....
I have few doubts about how operating system works.
Scheduler: Does the scheduler runs in a separate process(like any other process). What exactly happens at the time of swapping in new process(i know the processor registers and memory tables are updated, my question is how they are updated. Can we write a program to update the registers(sc, pc) to point to a different process).
The process schedule could feasibly run in a separate process, but such a design would be very inefficient since you would have to swap from one process to the scheduling process (which would then have to make several system calls to the kernel) and then back to the new process, as opposed to just placing the scheduler in the kernel where you will not need system calls nor need to swap contexts more than once. Therefore, the scheduler is generally in the exclusive realm of the kernel.
Here are the steps that occur:
The scheduler determines which process will run in the next time slot (through various different algorithms).
The scheduler tells the Memory Managing Unit (MMU) to use the page table for the next process to run (this is done by setting a register to point to the table).
The scheduler programs the Programmable Interrupt Timer (PIT) to generate an interrupt after N clock cycles.
The scheduler restores the state of the registers from when the process was last running (or sets them to default values for new processes)
The scheduler jumps to the address of the last instruction that was not executed in the process.
After N clock cycles, an interrupt occurs and the operating system recognizes it as caused by the PIT, which is registered to be handled by the scheduler.
The scheduler saves the state of the registers (including stack pointer, etc) and grabs the program counter of where the interrupt occured (and saves it as the address to jump to next time around) and then goes back to step 1.
This is just one example of how it can be done, and many of the low level details are architecture specific. Essentially all the registers (the program state) can be saved to any place in RAM (say a linked list of structures that represent processes each having space for the registers, etc) and the virtual address space (defined by page tables) can be arbitrarily swapped out.
So essentially your question:
"Can we write a program to update the registers to point to a different process?"
is simply stated, yet the answer is correct. We sure can.