Re: External dsect

2019-02-03 Thread Paul Gilmartin
On Wed, 30 Jan 2019 08:08:43 -0500, Peter Relson wrote:
>
>I'll quibble about the very title of this post. I'd say that there is no 
>such thing as an external dsect.
>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.
> 
That earns you the right to an RCF.  The HLASM Ref. uses "external DSECT"
three times, generally in connection with the DXD instruction.


On Sun, 3 Feb 2019 17:19:42 -0500, Steve Smith wrote:

>Bleah.  "Good form" may be in the eye of the beholder.  Personally, I see
>very little value in macro keywords that specify if or how to create one
>statement of output.  I'd rather they leave it to the programmer to code
>CSECTs, DSECTs, etc. where he wants them.
>
I believe DSECT={YES|NO} is valuable.  It saves the programmer not only
one instruction but the need to wrap the macro call in order to use
&SYSLOC LOCTR in order to restore the calling context.

I might prefer SECT={CSECT|DSECT|NONE} to support the programmer's
embedding multiple macros in one data area by entirely suppressing the
CSECT/DSECT instruction.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-02-03 Thread Steve Smith
Bleah.  "Good form" may be in the eye of the beholder.  Personally, I see
very little value in macro keywords that specify if or how to create one
statement of output.  I'd rather they leave it to the programmer to code
CSECTs, DSECTs, etc. where he wants them.

sas

On Sun, Feb 3, 2019 at 3:34 PM Seymour J Metz  wrote:

> It's good form to write a macro that, with an appropriate parameter, will
> generate either the CSECT or the DSECT.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-02-03 Thread Charles Mills
No argument.

An alternative is to place the xSECT statement before the macro invocation:

For the real storage:

MYPARMS CSECT
PARMMAC FOO=YES,BAR=NO

Everywhere else:

MYPARMS DSECT
PARMMAC FOO=YES,BAR=NO

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, February 3, 2019 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

It's good form to write a macro that, with an appropriate parameter, will
generate either the CSECT or the DSECT.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of
Peter Relson 
Sent: Wednesday, January 30, 2019 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

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.
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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-02-03 Thread Seymour J Metz
It's good form to write a macro that, with an appropriate parameter, will 
generate either the CSECT or the DSECT.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Wednesday, January 30, 2019 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

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.
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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-31 Thread scott Ford
I want to say thanks to everyone. My experience / knowledge has gaps so
when I have doubts or questions i come to this great repository of
experience to ask the questions.

Scott

On Wed, Jan 30, 2019 at 4:17 PM scott Ford  wrote:

> 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  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-5637Cary, 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.*
>


-- 



*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


Re: External dsect

2019-01-30 Thread scott Ford
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  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-5637Cary, 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


Re: External dsect

2019-01-30 Thread Don Poitras
In article 

 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-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-30 Thread Elardus Engelbrecht
Peter Relson wrote:

>I do agree with all the posts that you should not do a LOAD in an exit.

Thanks and I also agree with that. Many years ago, it was my responsibility to 
load a module with LOAD  EP= into a library using SMF UJI exit. That 
module is a DSECT containing a looong list of accounting codes be used in a 
JOB (...) statement.

Beside overhead issues, it was sometimes difficult to add a new client 
dynamically.

Now, we are just calling RACF. RACF will check if you may use an accounting 
code. Based on the RC and Reason code your batch job can run or simply fails 
with a stern message about usage of accounts...

I agree with Rob, that you rather, if possible, should use a parm-driven and 
command refresh instead of having to redo a DSECT assembly.

Thanks Peter for your helpful comments.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-30 Thread Peter Relson
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.
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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-29 Thread scott Ford
Yeah, guys this what I thought ECVT entry was the way to go..Rob I agree
very 80s. We have a ECVT table entry, so this much better way to go.
I wanted to make sure i know my options before I try to design it. Thanks
one and all, it’s very much appreciated.



On Tue, Jan 29, 2019 at 3:18 PM Charles Mills  wrote:

> Let me recommend that vendor word approach. We use it and it works well.
> You just want to define the structure that the word will point to in such a
> way that you do not paint yourself into an upward compatibility corner. The
> word is zero if you have not initialized it.
>
> Access could not be easier:
>
>  L  R1,FLCCVT-PSA(,0)  Point to CVT
>  L  R1,CVTECVT-CVT(,R1) Point to ECVT
>  L  R8,ECVTCTBL-ECVT(,R1)   Point to Cust Anchor Table
>  L  R7,CZ_from_CTBL(,R8)Load our word
>  LTRR7,R7  Is it there?
>
> I believe our own @Peter Relson is the custodian of the word assignments.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Christopher Y. Blaicher
> Sent: Tuesday, January 29, 2019 10:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: External dsect
>
> If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL
> word assigned to your company.  That word can be used to point to a CSA
> structure of your own making.  You can have a program that reads a parm
> file and sets appropriate values.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-29 Thread Charles Mills
Let me recommend that vendor word approach. We use it and it works well. You 
just want to define the structure that the word will point to in such a way 
that you do not paint yourself into an upward compatibility corner. The word is 
zero if you have not initialized it.

Access could not be easier:

 L  R1,FLCCVT-PSA(,0)  Point to CVT
 L  R1,CVTECVT-CVT(,R1) Point to ECVT
 L  R8,ECVTCTBL-ECVT(,R1)   Point to Cust Anchor Table
 L  R7,CZ_from_CTBL(,R8)Load our word
 LTRR7,R7  Is it there?

I believe our own @Peter Relson is the custodian of the word assignments.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 29, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
assigned to your company.  That word can be used to point to a CSA structure of 
your own making.  You can have a program that reads a parm file and sets 
appropriate values.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-29 Thread Matt Hogstrom
The approach would work but I think even a LOAD in a system exit is not a good 
idea.  As Chris said, if you are an ISV you may already have an ECVT entry.  
Today I’d almost expect that someone would update a dataset with the changes 
and then issue a MODIFY urApp,NEWPARMS=xxx and urApp would read the dataset, 
update the in-memory copy and manage all the serialization so your exit could 
just operate on what was in memory and not have to manage it at that level.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270

"Aut Inveniam Viam Aut Faciam" translated -
"I shall either find a way or make one."

The phrase has been attributed to Hannibal 
<http://en.wikipedia.org/wiki/Hannibal>; when his generals told him it was 
impossible to cross the Alps by elephant 
<http://en.wikipedia.org/wiki/Second_Punic_War>,

> On Jan 29, 2019, at 1:52 PM, Christopher Y. Blaicher  
> wrote:
> 
> If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
> assigned to your company.  That word can be used to point to a CSA structure 
> of your own making.  You can have a program that reads a parm file and sets 
> appropriate values.
> PS - Most system exits don't behave well with real I/O because they take too 
> long.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Rob Schramm
> Sent: Tuesday, January 29, 2019 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: External dsect
> 
> Scott,
> 
> Not to be overly critical, but isn't this scheme a little 1980's?  I had 
> thought most products had moved away from this and moved to parm-driven with 
> some sort of refresh or command driven override.
> 
> Not saying it won't work.. because it will.
> 
> I will let others comment on the specifics.
> 
> Rob Schramm
> 
> 
> 
> Sent from my BlackBerry - the most secure mobile device
> 
>   Original Message
> From: idfli...@gmail.com
> Sent: January 29, 2019 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply-to: IBM-MAIN@LISTSERV.UA.EDU
> Subject: External dsect
> 
> All:
> 
> I want to be able to have an options program for our product that the 
> customer updates.
> Then they would assemble/bind it and we can call it to pass options to our 
> exits. The exits are system type exits, so i know I/O is limited or not 
> existent. My question is if i want a program to build the dsect i need to see 
> an example i assume , please correct me if I am wrong, that i would have:
> 
> CSECT ...
> .
> DSECT
> 
> Below is a sample if found.
> 
> PRMDSECT DSECTPARM-DSECT (R7)
> 
>  USING *,R7   INFORM ASSEMBLER
> 
> PRMTRGT  DSCL8TARGET-PGM
> 
> PRMADDR  DSXL4TARGET-PGM LOAD-ADDRESS
> 
> PRMERRCD DSXL4TARGET-PGM ERROR-CODE
> 
> PRMRSA  EQU   *  BEGIN PARM-RSA
> 
> LOADPGM   CSECT
> 
>   USING *,R3   INFORM ASSEMBLER
> 
>   LAR3,0(,R15) CSECT ADDRESSABILITY
> 
>   L R7,0(,R1)  PARMAREA ADDRESSABILITY
> 
>   LAR9,PRMRSA  POINT TO OUR RSA
> 
>   XC0(72,R9),0(R9) ENSURE X'00'S
> 
>   LAR15,0(,R9) LOAD WITH OUR RSA-ADDRESS
> 
>   STR13,4(,R15)BACKWARD-CHAIN
> 
>   STR15,8(,R13)FORWARD-CHAIN
> 
>   LRR13,R15LOAD WITH OUR RSA-ADDRESS
> 
>  XCPRMADDR,PRMADDRENSURE X'00'S
> 
>  LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD
> 
>  STCM  R0,B'',PRMADDR STORE IN PARM-FWORD
> 
>   XRR1,R1  ENSURE X'00'S
> 
> BADLOAD  EQU   *
> 
>   STCM  R1,B'',PRMERRCD
> 
> RTN2CLLR EQU   *
> 
>  L R13,4(,R13)RESTORE CALLERS R13
> 
>  XC0(72,R9),0(R9) ENSURE X'00'S
> 
> *
> 
>  RETURN (14,12),RC=(15)   RESTORE AND RETURN
> 
> *
> 
>  LTORG ,
> 
>  YREGS ,  MVS REGISTER-MACRO
> 
> LOADPGM  AMODE 31  ,
> 
> LOADPGM  RMODE ANY ,
> 
>  END   ,
> 
> 
> I am think my exit could issue a LOAD for a program similar to above with 
> something like this:
> 
> OPTSPARM DSECT
> 
> OPTTBL   DS0F
> 
> LOGMSG

Re: External dsect

2019-01-29 Thread Christopher Y. Blaicher
If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
assigned to your company.  That word can be used to point to a CSA structure of 
your own making.  You can have a program that reads a parm file and sets 
appropriate values.
PS - Most system exits don't behave well with real I/O because they take too 
long.

Chris Blaicher
Technical Architect
Syncsort, Inc.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, January 29, 2019 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

Scott,

Not to be overly critical, but isn't this scheme a little 1980's?  I had 
thought most products had moved away from this and moved to parm-driven with 
some sort of refresh or command driven override.

Not saying it won't work.. because it will.

I will let others comment on the specifics.

Rob Schramm



Sent from my BlackBerry - the most secure mobile device

  Original Message
From: idfli...@gmail.com
Sent: January 29, 2019 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-to: IBM-MAIN@LISTSERV.UA.EDU
Subject: External dsect

All:

I want to be able to have an options program for our product that the customer 
updates.
Then they would assemble/bind it and we can call it to pass options to our 
exits. The exits are system type exits, so i know I/O is limited or not 
existent. My question is if i want a program to build the dsect i need to see 
an example i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECT    PARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DS    CL8    TARGET-PGM

PRMADDR  DS    XL4    TARGET-PGM LOAD-ADDRESS

PRMERRCD DS    XL4    TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LA    R3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LA    R9,PRMRSA  POINT TO OUR RSA

  XC    0(72,R9),0(R9) ENSURE X'00'S

  LA    R15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  ST    R13,4(,R15)    BACKWARD-CHAIN

  ST    R15,8(,R13)    FORWARD-CHAIN

  LR    R13,R15    LOAD WITH OUR RSA-ADDRESS

 XC    PRMADDR,PRMADDR    ENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XR    R1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)    RESTORE CALLERS R13

 XC    0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


I am think my exit could issue a LOAD for a program similar to above with 
something like this:

OPTSPARM DSECT

OPTTBL   DS    0F

LOGMSGS  DC    C'P',H'5',C'LOG=Y'

TRACE    DC    C'P',H'7',C'TRACE=N'

TBLEND   DC    X'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have to 
be re-entrant of course.  Is my thinking right all ?


Scott


*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


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: External dsect

2019-01-29 Thread Rob Schramm
Scott,

Not to be overly critical, but isn't this scheme a little 1980's?  I had 
thought most products had moved away from this and moved to parm-driven with 
some sort of refresh or command driven override.

Not saying it won't work.. because it will.

I will let others comment on the specifics.

Rob Schramm



Sent from my BlackBerry - the most secure mobile device

  Original Message  
From: idfli...@gmail.com
Sent: January 29, 2019 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-to: IBM-MAIN@LISTSERV.UA.EDU
Subject: External dsect

All:

I want to be able to have an options program for our product that the
customer updates.
Then they would assemble/bind it and we can call it to pass options to our
exits. The exits
are system type exits, so i know I/O is limited or not existent. My
question is if i want a program to build the dsect i need to see an example
i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECT    PARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DS    CL8    TARGET-PGM

PRMADDR  DS    XL4    TARGET-PGM LOAD-ADDRESS

PRMERRCD DS    XL4    TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LA    R3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LA    R9,PRMRSA  POINT TO OUR RSA

  XC    0(72,R9),0(R9) ENSURE X'00'S

  LA    R15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  ST    R13,4(,R15)    BACKWARD-CHAIN

  ST    R15,8(,R13)    FORWARD-CHAIN

  LR    R13,R15    LOAD WITH OUR RSA-ADDRESS

 XC    PRMADDR,PRMADDR    ENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XR    R1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)    RESTORE CALLERS R13

 XC    0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


I am think my exit could issue a LOAD for a program similar to above with
something like this:

OPTSPARM DSECT

OPTTBL   DS    0F

LOGMSGS  DC    C'P',H'5',C'LOG=Y'

TRACE    DC    C'P',H'7',C'TRACE=N'

TBLEND   DC    X'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have
to be re-entrant of course.  Is my thinking right all ?


Scott


*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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


External dsect

2019-01-29 Thread scott Ford
All:

I want to be able to have an options program for our product that the
customer updates.
Then they would assemble/bind it and we can call it to pass options to our
exits. The exits
are system type exits, so i know I/O is limited or not existent. My
question is if i want a program to build the dsect i need to see an example
i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECTPARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DSCL8TARGET-PGM

PRMADDR  DSXL4TARGET-PGM LOAD-ADDRESS

PRMERRCD DSXL4TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LAR3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LAR9,PRMRSA  POINT TO OUR RSA

  XC0(72,R9),0(R9) ENSURE X'00'S

  LAR15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  STR13,4(,R15)BACKWARD-CHAIN

  STR15,8(,R13)FORWARD-CHAIN

  LRR13,R15LOAD WITH OUR RSA-ADDRESS

 XCPRMADDR,PRMADDRENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XRR1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)RESTORE CALLERS R13

 XC0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


 I am think my exit could issue a LOAD for a program similar to above with
something like this:

OPTSPARM DSECT

OPTTBL   DS0F

LOGMSGS  DCC'P',H'5',C'LOG=Y'

TRACEDCC'P',H'7',C'TRACE=N'

TBLEND   DCX'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have
to be re-entrant of course.  Is my thinking right all ?


Scott


*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