IBM Mainframe Forum

The structure of my program looks like this

0) Standard prologue
1) Obtain storage for WORK31 and ...
2) Initialize it with a MVCL

3) Obtain storage for WORK24 and ...
4) Initialize it with a MVCL

5) I open the file using a dedicated CSECT called by BAKR - PR
6) I check the JCL parm using a dedicated CSECT called by BAKR - PR
7) I read the SYSIN ...
8) and i check it using a dedicated CSECT called by BAKR - PR
9) I perform the main task (still using a dedicated CSECT)
10) I close my file using a dedicated CSECT called by BAKR - PR
11) I release the storage and quit the program

I used this much of CSECT to avoid lack of registers.

and Yes, I am very picky when it comes to assembler programmingm at least for the programs I write.
to avoid surprises I prefer to fill up myself the proper addresses in the <copied> DCBs/DCBEs

for a plain DCB for example
here is my standard <open> sequence



just chatting about it, probably You already took care of that

{Replaced with correct snippet}

sensuixel wrote:I didn't know that using the linkage stack was slower than regular linkage.
I used a BAKR to build the linkage stack and then PR to exit (as taught by our instructor recently, but he didn't mentionned the performance issue).

I think your analysis on the DCBE is right, the DCBE must be somehow invalid or ignore.

By the way, my program is reenterable.

• Back in the 90s I carefully measured it, and I was quite surprised. Think about it. In z/Architecture BAKR saves 16 64-bit registers, and 16 32-bit access registers. In ESA/390, BAKR saves 16 32-bit registers and 16 32-bit access registers Conventional linkage saves 15 32-bit registers, and you may need fewer. In your OPEN_FIC and CLOSE_FIC, depending on the details, you might just need to save and restore reg 14.
• As for Mr. Sorichetti's comment about too many CSECTs. I thought about that issue, too, though in a different context. I wondered why you defined WORK24 as RMODE ANY. Then I realized you moved it to 24-bit storage, and then I realized you did not have any 24-bit address constants in it, so there was no issue about the RMODE ANY. Then I realized you had the reentrancy problem with the DCBE.

enrico-sorichetti wrote:and Yes, I am very picky when it comes to assembler programmingm at least for the programs I write.
to avoid surprises I prefer to fill up myself the proper addresses in the <copied> DCBs/DCBEs

for a plain DCB for example
here is my standard <open> sequence

Select all

000098 ...
000099 LA <DCBREG>,<DCBADDR>
000100 USING IHADCB,<DCBREG>
000101 MVC DCBDDNAM,<DDNAME>
000102 LA R15,<DCBEOFADDR>
000103 STCM R15,B'0111',DCBEODA
000104 OPEN ((<DCBREG>),(INPUT)),MF=(E,OPENLST)
000105 TM DCBOFLGS,DCBOFOPN
000106 BO <PROCESS>
000107 ...

just chatting about it, probably You already took care of that

Your code is more legible than mine.

i'm currently "rebuilding" my code, I'll get rid of BAKR - PR to improve efficiency.

sensuixel wrote:... I'll get rid of BAKR - PR to improve efficiency.

In practice, for this case, you won't notice any difference. You would need hundreds or thousands of calls to notice a difference.

I know it, but as a matter of principles i try, whenever i can, to use what seems to be the best practices

sensuixel wrote:You're right, I have modified the RMODE of WORK24 , i've replaced my RSECT by CSECT and removed the RENT option and
it works now ...

But i don't know if the problem comes from the APF or from the RENT (maybe both of it) , i'll go check that in the manuals.

Both, as I sort of explained earlier. With the DCBE pointer corrected, it should be reenterable.

You do not want to change the RMODE of your WORK24 CSECT/RSECT. That will have the effect of making the load module RMODE 24. I think the comment from someone else was because they thought the storage in WORK24 was going to be used in place, not moved below the line and the below the line copy would be used.

In another post, you talked about trying to use "best practices." I do not believe what you are doing falls under "best practices." I know it took me quite a while before I fully understood what you were trying to do. Once I did I thought, "Clever, but confusing," not because it is "wrong," but because it is not done the way many people do similar things. I won't go into details, but the way I have done dynamic allocation in most programs for 30 years falls into this category.

enrico-sorichetti wrote:and Yes, I am very picky when it comes to assembler programmingm at least for the programs I write.
to avoid surprises I prefer to fill up myself the proper addresses in the <copied> DCBs/DCBEs

for a plain DCB for example
here is my standard <open> sequence

Select all

 000098          ...
 000099          LA    <DCBREG>,<DCBADDR>           
 000100          USING IHADCB,<DCBREG>
 000101          MVC   DCBDDNAM,<DDNAME>
 000102          LA    R15,<DCBEOFADDR>
 000103          ST    R15,DCBEODAD
 000104          OPEN  ((<DCBREG>),(INPUT)),MF=(E,OPENLST)
 000105          TM    DCBOFLGS,DCBOFOPN
 000106          BO    <PROCESS>
 000107          ...   

just chatting about it, probably You already took care of that

Actually, the code to populate DCBEODAD is incorrect. The address is in 3 bytes, actually at DCBEODAD+1 or DCBEODA. The first byte of DCBEODAD is DCBBFTEK/DCBHIARC/DCBBFALN, depending on the bits that are used. DCBHIARC, of course, has been obsolete for nearly 40 years, but the other two elements, especially DCBBFTEK, are still valid.

{corrected above: if there is one piece of invalid code amongst many, that will be the code chosen as an example...}

For clarity I have edited the above posts with a different example provided by enrico.