IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Assambly code to get the jobname ?


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Tue Jul 07, 2015 11:37 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 08, 2015 12:06 am
Reply with quote

Search the forum for GETJOBI. It uses the EXTRACT Macro followed by control block traversing to get the Job-Name.

HTH....
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Wed Jul 08, 2015 12:30 am
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 08, 2015 2:30 am
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Wed Jul 08, 2015 4:54 am
Reply with quote

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
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Wed Jul 08, 2015 5:57 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Jul 08, 2015 6:30 pm
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Jul 09, 2015 6:17 am
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 09, 2015 4:39 pm
Reply with quote

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
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Thu Jul 09, 2015 6:49 pm
Reply with 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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 09, 2015 7:04 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Jul 09, 2015 7:52 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Jul 09, 2015 7:56 pm
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland

PostPosted: Thu Jul 09, 2015 8:05 pm
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Jul 09, 2015 9:45 pm
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Jul 09, 2015 10:28 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 09, 2015 11:13 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> PL/I & Assembler

 


Similar Topics
Topic Forum Replies
No new posts purge jobs with return code 0 and ret... JCL & VSAM 4
No new posts run rexx code with jcl CLIST & REXX 15
No new posts Compile rexx code with jcl CLIST & REXX 6
No new posts REXX code to expand copybook in a cob... CLIST & REXX 2
No new posts Using the Jobname parameter in a Qual... ABENDS & Debugging 1
Search our Forums:

Back to Top