|
View previous topic :: View next topic
|
| Author |
Message |
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Hi experts,
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 |
|
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Search the forum for GETJOBI. It uses the EXTRACT Macro followed by control block traversing to get the Job-Name.
HTH.... |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Thanks,
When i run that program , i got abend
| Code: |
********************************* 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 |
|
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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? |
|
| Back to top |
|
|
steve-myers
Active Member
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. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Hi Bill and Steve,
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.
| Code: |
//T14ASM JOB (T,TSP,TSP8000,4,WD33),'',CLASS=4,
// MSGCLASS=T,NOTIFY=TU14,
// RESTART=*
//GO EXEC PGM=TEST3
//STEPLIB DD DISP=SHR,DSN=TTAT.TSP.TU14.S370ASM.LOAD
//SYSOUT DD SYSOUT=* |
As return code is 0C4 is it means this program want access some storage area where it protect by system ?
Thanks |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
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. |
|
| Back to top |
|
|
steve-myers
Active Member
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. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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.
As with most code, variations are common.... |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
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 |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If all you need is to extract the job-number, then the following code will do this -
| Code: |
JOBNBR DS CL8
*
LLGT R10,540 CURRENT TCB
L R10,180(,R10) POINT TO JFCB
L R10,316(,R10) POINT TO SSID
MVC JOBNBR,12(R10) POPULATE JOB-NUMBER
|
HTH.... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
For documentation, what you need is the multi-volume (probably six for each) MVS Data Areas manuals for your OS.
There's a June 2015 Refresh list for z/OS V2R1 here. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
You can traverse Control Blocks in COBOL:
http://www-01.ibm.com/support/docview.wss?uid=swg21392963
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.
Outside of Production, you can have more fun. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
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.
You might find the information on control blocks in :
idcp.marist.edu/pdfs/ztidbitz/31%20zNibbler%20(zOS%20Control%20Blocks).pdf
useful in learning about z/OS control blocks.
Garry |
|
| Back to top |
|
|
steve-myers
Active Member
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. |
|
| Back to top |
|
|
steve-myers
Active Member
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. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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". |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
