Don exactly. I am having to reverse engineer a situation that was out of my control. I read what everyone said and i think the ECVT customer slot is much better. We dont provide our exit source, but we do provide framework in HLASM that includes a call to our actual code. Many years ago in a past life, we had external tables, tables that could be built and updated separate from the calling code. This was in a CICS program , i *think* because this was about 25+ yrs ago we had a CSECT and DSECT for the actual table. I dont feel sometime the older ways are so bad, but this is am opinion of course.
Scott On Wed, Jan 30, 2019 at 9:14 AM Don Poitras <poit...@pobox.com> wrote: > In article < > of19ca4142.d70dd9b8-on85258392.0047a325-85258392.00483...@notes.na.collabserv.com> > you wrote: > > I do agree with all the posts that you should not do a LOAD in an exit. > > I'll quibble about the very title of this post. I'd say that there is no > > such thing as an external dsect. > > Well, there is such a thing, but it's not what this thread is discussing. > A dsect is "external" if it is used like a DXD. i.e. the target of a > qcon. > > > A dsect is just a mapping. What you are talking about is simply an > > external CSECT of DC's for which you provide a DSECT to map. > > The OP of course knows how to initialize a csect. > > A DSECT could be used to help guide where the DC's go if wanted (such as > > by using ORG the_start+the_field_in_the_dsect). And of course the DSECT > > would be used to interpret the CSECT. > > If you're going to go the route of an initialized CSECT that a customer > > assembles, then you should probably provide a macro within the CSECT so > > that the customer is updating the macro (and the macro knows how to set > > the fields). > > Once the CSECT is initialized, there is only the question of whether it > is > > bound with your code (and thus addressable by v-con) or is located > > dynamically by your code. > > Peter Relson > > z/OS Core Technology Design > > -- > Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive > sas...@sas.com (919) 531-5637 Cary, NC 27513 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
