IBM Mainframe Forum

Hi everyone, I want to ask some questions to clarify concepts and examples.

Question 1:

The DCB Macro has a number of parameters, and sometimes all of the information can be found in the paremeters for the macro and sometimes not. Where does the assembler look for the DCB information and in what order?

Question 2:

Suppose I am reading the directory of a PDS using QSAM. I have only read a directory block into a 256-byte buffer and have located the first member name, so register 6 = the address of the first name.
How do I describe how to locate the next member name (I want its address in register 7)?

Question 3:

This is an example in the book but don't really know how to complete it.

Suppose we are using BSAM for input, the BLKSIZE is 450 and LRECL is 50. The DECB for the input file is called INDECB and the DCB is called INDCB. The data in the file is all ordinary text.

We have these variables:

BUFFER DC 450x'00'
TABLE DC 9CL50
EOT DS F

We have just read the first block into buffer and want to copy the records into the table and set EOT = the logical end-of-table address. It is possible the block is a short block (may be a short file).

What I am trying to figure out is how to write the code to do this (we are dealing here with only one block)??




Thanks, I will keep trying to read notes to figure it out.

anyone?

1. The assembler just sees the DCB attributes you have provided in the macro call. During OPEN processing OPEN merges DCB attributes from four sources -
   • DCB attributes specified in the DCB macro.
   • DCB attributes specified in JCL if not already in the DCB.
   • DCB attributes specified in the data set label if not already in the DCB.
   • DCB attributes altered by the “DCB exit” exit routine. The “DCB exit” exit routine is entered after the previously discussed merge has completed. It can be used to correct improper DCB attributes or insert missing DCB attributes.
2. You have already been given examples. Obviously you did not bother to read and understand them.
3. You have already been given examples. Obviously you did not bother to read and understand them.

pintu1228 wrote:anyone?

You allowed 9 hours for a response before posting this. You should be aware that responses on this forum are voluntary and based on the responder's interest and time available. Hence, you might get 17 responses in 2 hours and you may get ZERO responses in several days -- both are normal. However, it is considered rude (at best) to badger for responses. It often makes those people who would respond decide not to. If the question(s) you posted are so urgent, you should either do your own research instead of relying upon someone else, or pay a consultant to answer the question(s) for you. Furthermore, instead of relying on whatever book you are looking at, have you looked at the IBM reference materials readily available on the Internet? I know when I wrote a COBOL program to read a PDS directory several years ago, the IBM manuals were very explicit about things like navigating from one member to the next in the directory.

Thanks and didn't mean to badger for responses, I am actually looking at the IBM manuals.

Sorry Steve, looks like I split this from the old topic (pintu1228 , always start a new question, you can link to existing questions/answers if you find that useful) whilst you were in the process of posting your answer.

For your question 2. I first did this (I think) in 1969. I sort of recall the layout of a PDS directory block was in the OS/360 Utilities manual then. I don't recall ever seeing code to work through a directory block in an IBM publication. I know how I do this now; you have it already; the same code would work in 1969. I can no longer recall what I did in 1969, but it would require the same steps.

Your questions 1 and 3 are discussed in DFSMS Using Data Sets. Question 1 is also discussed in the JCL Reference manual. Your question 3: calculating the actual data read into a block is discussed in DFSMS Using Data Sets. You have how I do it, though I use different terminology than Using Data Sets, though the code is the same. See Determining the Length of a Block when Reading with BSAM, BPAM, or BDAM in Using Data Sets.

Thanks for your help, I will be reviewing your suggestions

So for the answers I have provided, can you tell me if my understanding is correct for each and is there a better way to do it?:

Question 2:

When we are reading PDS using QSAM, we can get details of every data member of the PDS. The first 2 bytes of the PDS block indicates the number of used byes of the block. Following those 2 bytes, the data member details are stored. The member name is 8 bytes long followed by 2 bytes used for relative track number and 1 byte is used as relative block number. The very next byte after this TTR contains information such as bit 0 indicates if member name is an alias or not, bits 1-2 indicate the number of pointers to locations with the member and bits 3-7 is the length of the user data field as the number of halfwords.

To locate next data member from PDS, do the following:

1. Read byte containing user data length
2. Remove additional bits
3. Convert halfword length into number of bytes
4. Starting from member name, add length of user data and length of other details to get exact address of the next data member name.

Question 3:




I don't know if I should ask this here or create another topic, but I have another question regarding a concept (linked list using dynamically-allocated links). What can I do to make it better or is what I have correct?:

Each link is 40 bytes in size, the contents of link are in this order:

--- a fullword which is a LEFT pointer
--- a fullword which is a RIGHT pointer
--- 32 bytes of data

So I can use (don't have to) EQUATE: LINKSIZE EQU 40, XSAVE, RETURN macros in my subroutines.

Base register should be 12 and I must define a save area.

Part 1: Write subroutine called NEWLINK which will dynamically allocate 1 link and return its address in a fullword parameter. (new link should be initialized: the pointers should have the value 0 and the data should be blanks)

Part 2: Write subroutine called DELINK which will deallocate a link whose address is provided in a fullword parameter.


Here is what I have so far:

Question 2

Properly speaking, your question 2 should be worded “When we are reading a PDS directory ...” In a technical sense using QSAM to read a directory is just a bit weird, but we always do it because most of us are just plain lazy. Your understanding of the PDS2INDC byte in a directory entry is correct.

Question 3, part 1

Your code is correct, but why are you doing LH/LTR? SH 2,14(,5) will work just as well, without the cost of the LH/LTR/BZ.

This isn't about code correctness, but about style. When you need to load something for use in what amounts to one instruction, use register 14, 15 or 1. Since those registers get clobbered by most system macros and even some instructions, like TRT or EDMK, they are safe and convenient to use for a couple of instructions, and you do not need to use registers better used for other purposes.

Question 3, part 2

In my work I use a lot of linked lists, but rarely use a double link where each element has the address of the next element and the previous element. I have also found removing a single element from a double linked list is difficult because removing the first element or last element require special processing. I've also found removing a single element is rarely done. I also mostly use LIFO (Last In First Out) chains as adding a new element at the start of the chain is easier and quicker than adding a new element at the end of a FIFO (First In First Out) chain. Now study this carefully, which you don't seem to do.
Now don't get me wrong: when it makes sense I use FIFO chains just as readily as LIFO chains.