Hello,
In some of the earlier older threads there were discussions about how to read the control blocks using cobol to retrieve information like job name, job number etc
Although many have suggested that they don’t recommend doing so, just wondering why it might be so?
Joined: 30 Nov 2013 Posts: 863 Location: The Universe
This is the Assembler for a Cobol callable routine. It is far more maintainable than any direct Cobol code.
Code:
* CALL GETJOBID(JOBID)
* JOBID DC CL8' '
GETJOBID CSECT
GETJOBID AMODE ANY
GETJOBID RMODE ANY
SAVE (14,1),,GETJOBID-&SYSDATE-&SYSTIME Save registers
L 1,0(,1) Load address where we store the ->
jobid
L 15,CVTPTR CVT -> TCB pointers -> TCB
L 15,CVTTCBP-CVTMAP(,15)
L 15,4(,15)
L 15,TCBJSCB-TCB(,15) TCB -> JSCB -> SSIB
L 15,JSCBSSIB-IEZJSCB(,15)
MVC 0(L'SSIBJBID,1),SSIBJBID-SSIB(15) SSIBJBID -> output
RETURN (14,1),RC=0 Restore registers & return
PRINT NOGEN
CVT DSECT=YES
IKJTCB
IEZJSCB
IEFJSSIB
END
This much of the listing may give you enough to create Cobol code.
Code:
000020 5810 1000 00000 14 L 1,0(,1)
000024 58F0 0010 00010 15 L 15,CVTPTR
000028 58F0 F000 00000 16 L 15,CVTTCBP-CVTMAP(,15)
00002C 58F0 F004 00004 17 L 15,4(,15)
000030 58F0 F0B4 000B4 18 L 15,TCBJSCB-TCB(,15)
000034 58F0 F13C 0013C 19 L 15,JSCBSSIB-IEZJSCB(,15)
000038 D207 1000 F00C 00000 0000C 20 MVC 0(L'SSIBJBID,1),SSIBJBID-SSIB(15)
/*********************************************************************
* *
**********************************************************************
say 'Job Name :' jobname
say 'Programmer name:' programmer
say 'Proc step name :' procstepname
say 'Step name :' stepname
say 'Message class :' msgclass
say 'Job number :' jobid
*********************************************************************/
return
Joined: 30 Nov 2013 Posts: 863 Location: The Universe
Nic Clouston wrote:
Nice answers but not to this question which is "why it is not a good idea to use COBOL for this?"
Quote:
using cobol to retrieve information like job name, job number
Quote:
many have suggested that they don’t recommend doing so
Quote:
just wondering why it might be so
Part of the answer lies in Prino's Rexx "solution,"which has all sorts of what is called in our trade, "magic numbers" -
tcb = ptr(540, 4)
The "magic number" here is 540. As far as I know it has been 540 (X'21C') since the first release of MVS. But before MVS, the data areas now known as PSATNEW and PSATOLD moved all over the place. CVTTCBP always pointed to PSATNEW guaranteed. The ratio between PSATNEW and PSATOLD (the 'magic number" 4 in my Assembler code) has been fixed since OS/360 Release 1; that's one "magic number" unlikely to change! I also point out these data areas in the PSA --
Code:
PSATNEW DC A(0) - TCB pointer. Field maintained for code
* compatability with previous MVS
* releases. DO NOT USE. @LQC
IEATCBP EQU PSATNEW - ALIAS
PSATOLD DC A(0) - Pointer to current TCB or zero if in SRB
* mode. Field fixed by architecture
and the formal definition of CVTTCBP -
Code:
CVTTCBP DC V(IEATCBP) - Address of PSATNEW.
Now notice, it is not A(PSATNEW-PSA): it is the external address of IEATCBP which is resolved only when the system is IPLd, as both the PSA and the CVT are part of the nucleus. The PSA is forced to virtual address (and real address) 0 through a Linkage Editor trick (and nucleus loader trick, as the nucleus is not loaded by regular program fetch) most programmers have long since forgotten.
In any event, I do not use PSATOLD in any production program: CVTTCBP is much safer, even though I doubt PSATOLD is going to move.
Going back to Prino's "solution" we have -
jscb = ptr(tcb + 180, 4)
and
ssib = ptr(jscb + 316, 4)
These "magic numbers" are likely to leak into Cobol or PL/I "solutions."
