Even so, I did eventually write a macro to handle DCBs from a 31-bit program. The macro does GEN, MOD, OPEN, CLOSE, GET, PUT and EXPOSE with dynamically allocated storage. GET and PUT can determine whether the dataset is FB or VB and read or write data accordingly, aka PL/I GET/PUT DATA (as I recall). While perhaps minor, it does make my coding a bit simpler. Plus it was fun to do, though I probably spent more time developing it than I will ever save having it.
-----Oprindelig meddelelse----- Fra: IBM Mainframe Assembler List <[email protected]> På vegne af Seymour J Metz Sendt: 19. september 2022 17:41 Til: [email protected] Emne: Re: Assembler courses 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-JnO6vXomWna7PrvoFwpUsf > G4c8sMvhFFvbWp8vTLAhS8cpooy5bLMBrphNiNZ4uZGvn7xWsF_1ElVlBXCptp7g_UL_NX > Y0kRVyaZvUhONOJb3mkQueVSYbEJPtisyJyZ-zCnXSbUiapwS2UW2uSaogiKBgOOQqe3uO > DiiK4pibnpZ7fSW74AMGlsaHIer8J9kjhhUNYbkUPDRsLWzT15xqvJI8mWqWj9RwoNaSDr > 0HfwF7nLFoD8aqXOhts9_QswG7ep6gQpdvzx3wHFv1D3ZHOOL9H3DftRi-tf51ekEJ8Nzy > FUxMEamBbpZH0c60-smhBohh3LIgS81wXKDMLwRnTwUh-bhjrkdjpQ7JbXzMwFJbPSLk8o > 7oVwu03MKXQQHkwO6zTPmPD2jDiWn9mhAkeD3VTo0ehtmXhEmBifdcEZtK/https%3A%2F > %2Fwww.phoenixsoftware.com%2F > >
