IBM Mainframe Forum

Does anyone here have any manuals or other resources they could share that would help learn how to get information from control blocks? I'm new to this so I'm not even sure I'm asking the correct question.

I've watched this: https://www.youtube.com/watch?v=L-scxwawCXA

and read this: http://zseries.marist.edu/pdfs/ztidbitz ... cks%29.pdf

And read some of the IBM manuals and was able to figure out the very basics but I still feel lost on how to actually do the conversions and everything to get the info I need. If I use the code from the video above I can do a little bit but I definitely can't do it on my own. Here's the rexx code from the video and some little additions I made, maybe it'll give a clearer picture of what I'm asking.



It's mostly the part at the bottom of the code, the CINFO and DREF parts that I'm not quite sure how to figure out.

Does anyone have any resources for learning more about it? Would learning assembler help me understand better? Also, I hope this is the right part of the forum to ask this

Without understanding the basics of Assembler, and IBM data types, one can hardly become familiar with zOS control blocks.

All available documentation on control blocks is in Assembler terminology. It can be found by typing in Google smth. like ‘ASCB fields reference’, or similar.

I understand where to find them(kind of, it's kind of a needle in a haystack thing for me at this point) using the mapping tables. What I don't really understand is why I'm converting things from decimal to hexadecimal, then from Character to Decimal, like here: DREF: RETURN C2D(BITAND(STORAGE(D2X(ARG(1)),4),'7FFFFFF'X))

Is that just my fundamental lack of understanding of assembler and the low level stuff? I don't actually have a job doing this stuff, I just have experience as an operator and in production support. I'm just trying to learn it on my own, so sorry if I'm asking stupid stuff

BigLenny wrote:I understand where to find them(kind of, it's kind of a needle in a haystack thing for me at this point) using the mapping tables. What I don't really understand is why I'm converting things from decimal to hexadecimal, then from Character to Decimal, like here: DREF: RETURN C2D(BITAND(STORAGE(D2X(ARG(1)),4),'7FFFFFF'X))

These questions are 99% related to REXX itself (with 1% required some understanding of IBM data architecture).
The acronyms used for REXX built-in conversion functions are really surprising at the first sight, but after learning some examples of their usage one can get really familiar with them.

The letter 'C' in this naming convention in fact means rather 'byte', not 'character'.
So 'C2D' means 'convert a sequence of binary bytes to its decimal value'.

For instance the string '0011'x (those are two non-non-dispayable characters) is converted to "17" as decimal presentation of hexadecimal 11.
In REXX, any decimal value is stored exactly as its character presentation, so +17 and "17" are absolutely equivalent in REXX.
Etc.

These users thanked the author sergeyken for the post:

BigLenny (Mon Feb 14, 2022 8:02 pm)

Interesting, I don't think I would have figured that out without your help. Every time I look into something on the mainframe there seems to be 100 different rabbit holes to go down each with a dozen new things to learn.

I'll keep playing around with it now that I know. Thanks sergey!

I've been in this game for more than 50 years, and I still get lost from time to time. Recently, for example, I wanted to get to the ACEE to get the userid for the address space. There is a reference in the TCB (TCBSENV), but that turned out to be a dry hole. Eventually I went to the ASCB->ASXB->ACEE. As BigLenny has already noted, doing this search in Rexx can be confusing, to say the least because native Rexx requires these funny functions which Sergeyken noted.

Now I had the advantage of doing this search in Assembler, so I had the control block definitions PSAAOLD->ASCB, ASCBAXCB->ASXB,
ASXBSENV->ACEE, ACEEUSRI contains the userid, but I still had to read through the control definitions in SYS1.MACLIB and SYS1.MODGEN, rather that use these mysterious offsets xxx+100, for example, in Rexx.

Back in 1968, when I started, there was no SYS1.MODGEN, which didn't appear until 1972 or later, and that was because of the limited storage capacity of the disk drives in 1968. The OS/360 SYSRES in 1968 was designed around the 2311, a massive 7 1/4 megabyte device, and SYS1.LINKLIB. SYS1.MACLIB, and the other libraries all had to fit in this 7 1/4 megabytes. We had to depend, all too often, on references from printed manuals, so xxx+100 in our code was all too common.

Of course, in 1968, there was no ASCB, ASXB, or ACEE, which did simplify matters

These users thanked the author steve-myers for the post:

BigLenny (Tue Feb 15, 2022 8:03 am)

Maybe I'll try learning some assembler after I do a little more of this with rexx. I can't even imagine trying to do stuff with control blocks without the internet though. Having to look through paper binders or whatever you had sounds like a nightmare. That's probably why a lot of the older guys know so much though.

Maybe, just running a simple test on various REXX conversion function would help a little with this mess?

Please note that any produced string which includes only characters '0'-'9' is considered as normal decimal value in any REXX arithmetic expression, even if it is the result of conversion "to binary", or "to hexadecimal".

Also, any decimal numeric value is considered as string in string-expected expression


Conversion Functions

B2X Returns a string, in character format, that represents the input binary
string converted to hexadecimal. (Binary to hexadecimal)
        

C2D Returns the decimal value of the binary representation of the input
string. (Character to Decimal)


C2X Returns a string, in character format, that represents the input string
converted to hexadecimal. (Character to Hexadecimal)
       

D2C Returns a string, in character format, that represents the input decimal
number converted to binary. (Decimal to Character)


D2X Returns a string, in character format, that represents the input decimal
number converted to hexadecimal. (Decimal to Hexadecimal)


X2B Returns a string, in character format, that represents the input
hexadecimal string converted to binary. (Hexadecimal to binary)



X2C Returns a string, in character format, that represents the input
hexadecimal string converted to character. (Hexadecimal to Character)
              

X2D Returns the decimal representation of the input hexadecimal string.
(Hexadecimal to Decimal)

These users thanked the author sergeyken for the post:

BigLenny (Wed Feb 16, 2022 8:47 am)

Dang, thanks for doing that for me!

Just to make sure I understand.
For this one:
C2X Returns a string, in character format, that represents the input string
converted to hexadecimal. (Character to Hexadecimal)



The 'A' is the input string, the "C1" is the input string in hex(EBCDIC). Then rexx stores 'C1' as 'C3F1'x, because to rexx everything is a string, right?

BigLenny wrote:Dang, thanks for doing that for me!

Just to make sure I understand.
For this one:
C2X Returns a string, in character format, that represents the input string
converted to hexadecimal. (Character to Hexadecimal)

Select all

C2X( 'A' ) = "C1" = 'C3F1'x
 

The 'A' is the input string, the "C1" is the input string in hex(EBCDIC). Then rexx stores 'C1' as 'C3F1'x, because to rexx everything is a string, right?

1) input string of one character "A" is considered as a byte with 'C1'x as its content
2) byte 'C1'x is converted to its character presentation as new string: "C1" - if further used in any string expression
3) but the same two-character string contents "C1" will be equivalent to 'C3F1'x value (if ever used in further conversion by any C2...() function, or similar situation)

that is:
C2X( "C1" ) considered as C2X( 'C3F1'x ) ==> "C3F1" as a string
X2C( "C1" ) ==> 'C1'x or equivalent "A" as a string
C2D( "C1" ) considered as C2D( 'C3F1'x ) ==> either "50161" as a string, or equivalent +50161 as a numeric (depending on context where used)

These users thanked the author sergeyken for the post:

BigLenny (Wed Feb 16, 2022 8:22 pm)