What's the issue with DCB? You move a DCB from your code CSECT to your below 
the line work area and change whatever can't be assembled in, using the DCBD 
mapping. IMHO, the GENCB and MODCB macros are clumsier than just using RYO 
code, so I don't feel their absence for DCB. 

Usually I don't explicitly modify the DCB, but if the exit list needs to point 
to the work area, e.g., for JFCB, then a change to DCBEXLST is required. More 
rarely I change other fields.

Note: i generally copy the DCB as part of a big block of constants, rather than 
copying it separately.

________________________________________
From: IBM Mainframe Assembler List <[email protected]> on behalf 
of John McKown <[email protected]>
Sent: Saturday, September 17, 2022 12:39 PM
To: [email protected]
Subject: Re: Assembler courses

On Sat, Sep 17, 2022 at 10:29 AM Ed Jaffe <[email protected]>
wrote:

> On 9/17/2022 2:06 AM, Abe Kornelis wrote:
> > Starting with reentrant programming seems a pretty tough call.
>
> Not sure why re-entrant programming should be considered heavy lifting.
> Would not any assembler course teach about USING?
>

For me, the biggest problem in making something reentrant is if I need to
use a DCB. There is no way, that I know of, to generate a DCB in a
GETMAIN'd area. For ACB, there is a GENACB. Too bad z/OS cannot access
non-VSAM datasets using an ACB. From what I've read, z/VSE can in some
instances. I now like to write "pure" code. That is, code which does not
modify anything in the CSECT. All modifiable data is in GETMAIN'd
storage (OK, actually I use STORAGE OBTAIN in HLASM).



>
> A typical non-reentrant program has a single code/data segment and a
> single USING.
>
> A typical reentrant program has two segments: one for code and one for
> data -- each with its own USING. This has been common practice on other
> platforms (e.g., Intel) for decades.
>
> If I were to teach an HLASM course, I can envisage my very first
> recommended program organization diagram showing both a code and a data
> segment and never once suggesting at any time during the class that code
> and data can be (or ever historically were) mixed. Example:
>
> | R12 -> .---------.    R13 -> .---------.
> |        |         |           |         |
> |        |  Code   |           |  Data   |
> |        | Segment |           | Segment |
> |        |         |           |         |
> |        '---------'           '---------'
>
> > Baseless should - I guess - pose less of a challenge.
>
> Agreed. I would not make mention of based branches until the more
> advanced portions of the class.
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://secure-web.cisco.com/1wXxE3ULjuVdLd9AKv-JnO6vXomWna7PrvoFwpUsfG4c8sMvhFFvbWp8vTLAhS8cpooy5bLMBrphNiNZ4uZGvn7xWsF_1ElVlBXCptp7g_UL_NXY0kRVyaZvUhONOJb3mkQueVSYbEJPtisyJyZ-zCnXSbUiapwS2UW2uSaogiKBgOOQqe3uODiiK4pibnpZ7fSW74AMGlsaHIer8J9kjhhUNYbkUPDRsLWzT15xqvJI8mWqWj9RwoNaSDr0HfwF7nLFoD8aqXOhts9_QswG7ep6gQpdvzx3wHFv1D3ZHOOL9H3DftRi-tf51ekEJ8NzyFUxMEamBbpZH0c60-smhBohh3LIgS81wXKDMLwRnTwUh-bhjrkdjpQ7JbXzMwFJbPSLk8o7oVwu03MKXQQHkwO6zTPmPD2jDiWn9mhAkeD3VTo0ehtmXhEmBifdcEZtK/https%3A%2F%2Fwww.phoenixsoftware.com%2F
>
>

Reply via email to