I know how to use REXX to get jobname (eg, get the RC for jobname XXXX) but how to do the same thing in assambly? I did the search on interent found use control block TIOCNJOB ? Any book i can read about this control block ?
I found following code , dont know why use many USING instruction ??
Thanks
Code:
ADDRESS KEY CB'S
----------------
USING PSA,0
L 3,PSAAOLD LOCATE ASCB
USING ASCB,3
L 4,PSATOLD LOCATE TCB
USING TCB,4
L 5,TCBTIO LOCATE TIOT
USING TIOT1,5
L 6,TCBJSCB LOCATE JSCB
USING IEZJSCB,6
L 7,ASCBASXB LOCATE ASXB
USING ASXB,7
L 8,ASXBSENV LOCATE ACEE
USING ACEE,8
********************************* TOP OF DATA **************
IEF236I ALLOC. FOR T14ASM GO
IEF237I 51A2 ALLOCATED TO STEPLIB
IEF237I JES2 ALLOCATED TO SYSOUT
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000010
TIME=14.49.42 SEQ=01164 CPU=0000 ASID=00E3
PSW AT TIME OF ERROR 078D0000 C0404040 ILC 2 INTC 10
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW IS UNAVAILABLE AT THIS TIME
GR 0: 4040D1D6 1: C2F4F0F1
2: F8F00000 3: 00000000
4: 00000000 5: 00000000
6: 00000000 7: 00000000
8: 00000000 9: 00000000
A: 00000000 B: 00000000
C: 00000000 D: 00006008
E: 40404040 F: 00000000
END OF SYMPTOM DUMP
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
I have the same sub-program on my work system. Did you call it from a main-module? Besides the 32-bytes for the parms, did you pass 128-bytes of re-entrant storage?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Bill - look at the registers and PSW. The trouble is, all the code we see is the loads for various control blocks. That looks OK, but the problem seems to me to be linkage issues. All we really know is the registers are screwed up, and there's a hint, based on the PSW, somewhere the code did a BR 14.
The code to get control block addresses looks OK to me, so I don't think that's the problem, but there's just not enough info to dig into this.
Thanks for your answer. for your question "Did you call it from a main-module? Besides the 32-bytes for the parms, did you pass 128-bytes of re-entrant storage?"
I am not sure about your questions. what I did is just complie the program and return code is 0. then i use following jcl to run it and get abend.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If TEST3 is the program Bill pointed out to you, that is not going to work. Bill makes clear in his follow-up that at least two parameters are required. When you use EXEC PGM= you only get one parameter (that which is specified as PARM) and don't get a second data-area. S0C4 sounds like a potential immediate or subsequent result of that.
Write a small program and in there use the program Bill pointed to as a sub-program.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Jack - Many programs are intended to be called via // EXEC PGM=xxx. The GETJOBI program is intended to be called from another program. The example call interface in the program comments appears to be Cobol, so you need to write a Cobol program to call it, or at the least a program in another language - say Assembler - that can replicate the Cobol CALL.
Mr. Woodger's comments about 2 parameters is incorrect. The data area passed from the calling program includes a work area following the data area where data is returned.
Personal opinion: this GETJOBI program is a prime example why so many people avoid Assembler.
For example -
LLGT R15,540
L R15,208(,R15)
L R15,20(,R15)
LLGT is a very obscure instruction, for three reasons.
The G in the instruction implies it is loading the 64-bit register 15, and as the following instructions make clear, the program is not an AMODE 64 program.
Actually, if you lookup the LLGT instruction, you'll find it clears the high order 32 bits of reg 15, and just loads data into bits 32 to 63 of reg 15.
What's this 540? I grant the "ADDRESS CURRENT TCB" comment gives a clue as to the reason the instruction is being executed, but, still ... I grant the more correct PSATOLD-PSA(0) is nearly as bad.
The 208 and 20 in the next 2 instructions have the same issues. A prime rule in Assembler is to avoid "magic" numbers as in those three instructions - and "magic" numbers abound in the remainder of GETJOBI.
EXTRACT (R10),'S',FIELDS=TIOT,MF=(E,EXTRPLST)
The EXTRACT macro is fine, as far as it goes. It has been around forever. However, the program has already obtained the current TCB address. Guess what? The TCB already has the address of the TIOT; it's much quicker to simply load its address from the TCB, and avoid the multiple instructions and the parameter list in the EXTRACT macro.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Since the introduction of CICS/TS 4.2, IBM has chosen to use LLGT instead of a plain old Load. The three instructions actually comprise the CICS Macro DFHAFCD TYPE=LOCATE and has been coded with these same three instructions since CICS/ESA 3.1, over 20 years ago. These three instructions were hard-coded in GETJOBI rather than include the appropriate CICS SDFHMAC for SYSLIB during Assembly, as many shops have standard Assembly/Compile jobs and Batch Assemblies don't normally include a SYSLIB concatenation pointing to a CICS PDS.
As far as the hard-coded offsets, using decimal or hex shouldn't matter, although coding decimal will give you the hex interpretation after Assembly, so you get both.
Loading the TCB address a second time with the LLGT (or L) rivals that of less than a Picosecond of worry and it does not need to be discussed further.
Quick is a relative term on today's machines and with their unconstrained abilities, immeasurable time considerations can be an unnecessary distraction.
I am still not understand that why this program has to be called by another program ? Are there some insturctions in GETJOBI are made for this purpose ?
I want to know more about TIOT and TCB address or other relative control block , which book is take about this in details ?
I don't consider it a good idea for Production to use anything which does not rely on IBM-provided language materials which they update as required. So using the Assembler macros provided for the task.
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
Quote:
Hi steve,
I am still not understand that why this program has to be called by another program ? Are there some insturctions in GETJOBI are made for this purpose ?
I want to know more about TIOT and TCB address or other relative control block , which book is take about this in details ?
Thanks
This (sub)program has to be called by another program because that was the way it was designed to be used. It requires the parameters that it was written to require from the calling program.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Bill O'Boyle wrote:
... Since the introduction of CICS/TS 4.2, IBM has chosen to use LLGT instead of a plain old Load. The three instructions actually comprise the CICS Macro DFHAFCD TYPE=LOCATE and has been coded with these same three instructions since CICS/ESA 3.1, over 20 years ago. ...
z/Architecture and the LLGT instruction did not exist 20 years ago. z/Architecture is 15 years old.
Technically, its use can be considered dangerous, since it destroys bits 0 to 31 of register 15, which may not be saved and restored. Now let me add this has not been an issue in my code, where I use "grande" instructions without worrying about whether bits 0 to 31 in a register have been correctly preserved. Still, it is a concern, and sooner or later not following through in this matter is going to break something. The only question is when?
IBM coding conventions in Assembler about the use of "magic" numbers are pretty strict in open code. They are more lenient in macros, though it can be argued they should not be. But, I don't like "magic" numbers and try to avoid them, especially in something I post.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
jackzhang75 wrote:
Hi steve,
I am still not understand that why this program has to be called by another program ? Are there some insturctions in GETJOBI are made for this purpose ?
I want to know more about TIOT and TCB address or other relative control block , which book is take about this in details ?
Thanks
Jack, you are correct. Much of this I learned 40 or more years ago. After 40 years I can't tell you how I found this. In fact, when you get right down to it, it's not relevant today.
Today, I write
Code:
L 15,CVTPTR
L 15,CVTTCBP-CVTMAP(,15)
L 15,4(,15)
L 15,TCBTIO-TCB(,15)
MVC JOBNAME,TIOCNJOB-TIOT1(15)
to get the current jobname. This is the exact same code I would write in 1969, though in 1969 I would be forced to use "magic" numbers for data areas since IBM was reluctant to supply mapping DSECTs for major control blocks like the CVT, TCB and the TIOT. In 1969 I had to use printed documentation that has been somewhat replicated in manuals with different titles than in 1969. Unless I could find other people's code, I had to dig through the manuals, just as you have to. There aren't many short cuts. Now you have internet resources like this one, which we did not have in 1969, which can serve as a short cut sometimes. In 1969 there were other resources, most of which no longer exist, us beginners could and often did, use.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Quote:
z/Architecture and the LLGT instruction did not exist 20 years ago. z/Architecture is 15 years old.
You've misunderstood. CICS/TS 4.2 was released around 3 years ago and this is when the DFHAFCD TYPE=LOCATE Macro was changed from using an "L" to using an "LLGT".
