Scott Ballentine corrected my "expectation".
The default default, in the absence of any routcode, desccode, mcsflag and
CONSOLxx definition is routcodes 1-16.
Many exits do not run in environments where WTP (routcode 11) would work. Some
SMF exits, I believe, describe how to issue messages from
The code runs in an exit
In case it matters (unlikely as that is), what kind of "exit"? At least "is it
some sort of WTO-related exit"?
--> No, it is not a WTO-related exit.
Is there something in the WTO parameters that causes the IEF170 message to
disappear ?
Maybe a combination of MCSFLAG,
The code runs in an exit
In case it matters (unlikely as that is), what kind of "exit"? At least "is it
some sort of WTO-related exit"?
Is there something in the WTO parameters that causes the IEF170 message to
disappear ?
Maybe a combination of MCSFLAG, DESC and ROUTCDE ?
The first questio
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Abell
Sent: Tuesday, October 18, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO and IEF170I message
And she was deemed to possibly your next President. YIKES
John T. Abell
Tel: 800-295-7608 Option 4
President
Yikes indeed!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Abell
Sent: Tuesday, October 18, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO and IEF170I message
And she was deemed to possibly your next
As you have not specified ROUTCDE, CONSOL** takes over. Probably includes 11.
On Tue, 18 Oct 2022 13:37:35 -0500 Pierre Fichaud wrote:
:>I issue a plain WTO :wto 'This is a message'
:>I also issue a WTO :wto text=dsa_wtotext,mf=(e,dsa_wtoarea)
:>In both cases the WTO appears in the
And she was deemed to possibly your next President. YIKES
John T. Abell
Tel:800-295-7608Option 4
President
International: 1-416-593-5578 Option 4
E-mail: john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609
International: 1-416-593-5579
International So
Tony,
I was one of those 37x5 people for a lot of years working VTAM/NCP/NPSI ...
Scott
On Wed, Dec 4, 2019 at 4:21 PM Tony Harminc wrote:
> On Tue, 3 Dec 2019 at 08:36, Peter Relson wrote:
>
> >
> > Regarding both of the anchor tables: slots 1009-1024 are reserved for
> > customer usage (i.e
On Tue, 3 Dec 2019 at 08:36, Peter Relson wrote:
>
> Regarding both of the anchor tables: slots 1009-1024 are reserved for
> customer usage (i.e., the owner of the system), in whatever way they
> choose. Those slots will never be "given out". I do agree that it's
> unfortunate that 30+ years ago
-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
And he later sent out a mea culpa e-mail correcting himself.
Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Monday, December 2, 2019
M Mainframe Discussion List On Behalf
> Of Seymour J Metz
> Sent: Monday, December 2, 2019 5:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WTO
>
> EXTERNAL EMAIL
>
>
>
>
>
> Whatever Peter did or did not point out in some other message, he wrote
> Pete
Subject: Re: WTO
EXTERNAL EMAIL
Whatever Peter did or did not point out in some other message, he wrote Peter
wrote "Upon request (to me), IBM assigns to an ISV a slot in the anchor tables
pointed to by CVTCTBL".
--
Shmuel (Seymour J.) Metz
https://nam01.safelinks.protection.outloo
Peter,
To err is human, forgive divine, couldn’t resist it. I remember requesting
ours.
Scott
On Tue, Dec 3, 2019 at 9:32 AM Gord Tomlin
wrote:
> On 2019-11-28 21:28, Peter Relson wrote:
> > I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and
> > ECVTCTB2 as the pointer to t
On 2019-11-28 21:28, Peter Relson wrote:
I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and
ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL).
We arranged a slot in ECVTCTBL with you many years ago, but we never
heard about ECVTCTB2. Do we automatically have the same
Regarding CVTCTBL:
I already confessed my error and corrected it in a post subsequent to when
I posted that error.
The laws of physics make it kind of unlikely that one would be able to
post a fix to an append before the post of the append with the error.
Sometimes it is just necessary to hope t
anchor tables pointed to by CVTCTBL".
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of Steve Smith
> Sent: Monday, December 2, 2019 5:21 PM
> To:
From: IBM Mainframe Discussion List on behalf of
Steve Smith
Sent: Monday, December 2, 2019 5:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several
days ago. Both fields are in the ECVT:
ECVTCTBL DCV(CSRCTABL) Custo
Mainframe Discussion List on behalf of
scott Ford
Sent: Monday, December 2, 2019 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Lennie,
My understanding based on my notes from Peter is it’s the ECVTCTBL which is
+ x’CC’ into the ECVT. The customer anchor varies on it’s offset into the
November 28, 2019 10:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WTO
>
> Peter,
>
> On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data
> Areas manuals in the ECVT and I can find the field in the IHAECVT macro on
> the system.
>
> I can find no r
Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several
days ago. Both fields are in the ECVT:
ECVTCTBL DCV(CSRCTABL) Customer anchor table.
* Slots assigned by IBM.
...
ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2
*
-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Peter,
On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data
Areas manuals in the ECVT and I can find the field in the IHAECVT macro on the
system.
I can find no reference to the CVTCTBL in the Data Areas or in the CVT macro.
Is this intended
behalf of
Rupert Reynolds
Sent: Saturday, November 30, 2019 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Whatever happened to CVTUSR? Back in the 1990s we used to have (from
memory) a started task that came up briefly during IPL and it allocated
storage (I forget what key, but read o
, November 30, 2019 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
I think the problem with CVTUSER is that there is only one field but lots of
"users" (customer, vendor, other customer department, other vendor, ...).
Charles
-Original Message-
From: IBM Mainframe Discu
ssion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, November 30, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote:
>I think the problem with CVTUSER is that there is
-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Yes, using CVTUSER sensibly for a whole organisation requires authorised
code to run at IPL time, which must allocate a USERVT in common storage and
point CVTUSER at that.
There will be other ways, but once that work is done, it is relatively
little work to use i
Dymoke-Bradshaw
Sent: Sunday, December 1, 2019 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
I seem to recall there was another such pointer in the SMF structures and I
thought the Nasty Wet Monster Bank used that. But maybe I am mixing things up.
Could have been some other bank.
These
Peter,
My issue with the exit was a user error ( mine ) we didnt copy and LLA
fresh the right library.
Scott
On Sun, Dec 1, 2019 at 10:22 AM Lennie Dymoke-Bradshaw <
lenni...@rsmpartners.com> wrote:
> I seem to recall there was another such pointer in the SMF structures and
> I thought the Nasty
I seem to recall there was another such pointer in the SMF structures and I
thought the Nasty Wet Monster Bank used that. But maybe I am mixing things up.
Could have been some other bank.
These fields were great for local mods and I made extensive use of the CVTUSER
field in the 1980s to hold f
I confess I thought we were talking about a single installation.
But as I said, I was asking mainly out if interest, and to see whether IBM
have done anything with it, rather than making a recommendation.
Ruz
On Sun, 1 Dec 2019, 14:28 Peter Relson, wrote:
> Regarding CVTUSER, the problem, as C
Regarding CVTUSER, the problem, as Charles Mills alluded to, is that at
this point it is hard to "know" that no one else is using it.
It "should" be used only only with the approval of the customer that
"owns" the system.
But at this point, if you can't know that, many feel it not worth the
ris
Behalf
Of Rupert Reynolds
Sent: Saturday, November 30, 2019 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Yes, using CVTUSER sensibly for a whole organisation requires authorised
code to run at IPL time, which must allocate a USERVT in common storage and
point CVTUSER at that.
There will be
>> >
>> > Charles
>> >
>> >
>> > -----Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
>> > Behalf Of Paul Gilmartin
>> > Sent: Saturday, November 30, 2019 12:20 PM
>
fic "user" data you
> > need. I suspect the overhead for N/T services -- while pretty efficient
> --
> > is greater.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.ED
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Saturday, November 30, 2019 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WTO
>
> On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote:
>
> >I think the problem with CVT
spect
the overhead for N/T services -- while pretty efficient -- is greater.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Saturday, November 30, 2019 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote:
>I think the problem with CVTUSER is that there is only one field but lots of
>"users" (customer, vendor, other customer department, other vendor, ...).
>
Is this a relic of single address space design?
Is this something better addressed
nolds
Sent: Saturday, November 30, 2019 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
ahem! I meant to say CVTUSER, a very different field from CVTUSR :-)
On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote:
> Whatever happened to CVTUSR? Back in the 1990s we used to have (from
> memory
ahem! I meant to say CVTUSER, a very different field from CVTUSR :-)
On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote:
> Whatever happened to CVTUSR? Back in the 1990s we used to have (from
> memory) a started task that came up briefly during IPL and it allocated
> storage (I forget what key, b
Whatever happened to CVTUSR? Back in the 1990s we used to have (from
memory) a started task that came up briefly during IPL and it allocated
storage (I forget what key, but read only in the general case) for a vector
table, pointed CVTUSR at that, and then it stopped itself.
So if I was (say) at N
Lennie wrote:
Is this intended to be undocumented?
Is there a published list of the existing assignments of those slots?
To the first: it is documented. To the extent appropriate, that being
commentary in the data area book and showing the fields as "PI".
To the second: no.
It is up to each I
Thanks Peter. That makes sense.
Given that you have not replied regarding the existing slot assignments, I will
assume they are not published until I find differently.
Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web: www.rsmpartners.com
'Dance like no one is watching.
Sigh. Sorry.
I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and
ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL).
<>
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff /
Peter,
On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data
Areas manuals in the ECVT and I can find the field in the IHAECVT macro on the
system.
I can find no reference to the CVTCTBL in the Data Areas or in the CVT macro.
Is this intended to be undocumented?
Is there a
Peter,
Exactly, btw sometimes we ask questions but the decisions are not ours for
example.
Scott
On Thu, Nov 28, 2019 at 10:30 AM scott Ford wrote:
> Jon,
> I agree but this is part of our bread and butter, makes us our money.
>
> Scott
>
> On Thu, Nov 28, 2019 at 9:29 AM Peter Relson wrote:
Jon,
I agree but this is part of our bread and butter, makes us our money.
Scott
On Thu, Nov 28, 2019 at 9:29 AM Peter Relson wrote:
>
> If you really need speed, check if IBM has any user vector table entries
> specifically assigned for customer use. 4 load instructions instead of
> searching
If you really need speed, check if IBM has any user vector table entries
specifically assigned for customer use. 4 load instructions instead of
searching thru a chain. IBM assigns each entry (e.g. product vendor
request). I vaguely recall it being called CSRCTABL but I could be wrong.
Upon r
ations.)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jon Perryman
Sent: Thursday, November 28, 2019 1:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Wednesday, November 27, 2019, 08:20:47 AM PST, scott Ford
On Wednesday, November 27, 2019, 08:20:47 AM PST, scott Ford
wrote:
> My big issue I was at the mercy of CA code. Not blaming them,
> but it’s a CA product and I wished their doc was better.
If you are talking about the security exit samples, then they accomplished the
desired results by
On Wednesday, November 27, 2019, 04:39:07 AM PST, John McKown
wrote:
> Total agreement that it is bad form in today's world. For subsystems, there
> is the SSCT to anchor things. And, as I do for my re-entrant code: a
> Name/Token pair (primary address space level) to hold a 64-bit pointer
John,
Absolutely, my big issue I was at the mercy of CA code. Not blaming them,
but it’s a CA product and I wished their doc was better.
Scott
On Wed, Nov 27, 2019 at 7:39 AM John McKown
wrote:
> On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz wrote:
>
> > Of course it was reentrant, but was i
On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz wrote:
> Of course it was reentrant, but was it good form? I prefer to protect code
> against wild stores by marking it as r/o.
>
Total agreement that it is bad form in today's world. For subsystems, there
is the SSCT to anchor things. And, as I do
, November 26, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz wrote:
> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modifi
On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz wrote:
> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modified itself; AFAIK they have cleaned up that abomination.
>
I agree that it's an abomi
behalf of Jon
Perryman
Sent: Monday, November 25, 2019 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford
wrote:
> My chief complaint is samples.
> I spend a lot of time digging for examples.
> Working examples which I
Great I will look
On Mon, Nov 25, 2019 at 5:38 PM Jon Perryman wrote:
>
>
> On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford <
> idfli...@gmail.com> wrote:
>
> > My chief complaint is samples.
> > I spend a lot of time digging for examples.
>
> > Working examples which I can refer
On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford
wrote:
> My chief complaint is samples.
> I spend a lot of time digging for examples.
> Working examples which I can refer to and understand
> (prototype) before I start writing code.
CBTTAPE.ORG has tons of real world code
.EDU] On
> Behalf Of scott Ford
> Sent: Monday, November 25, 2019 7:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WTO
>
> David,
>
> It’s the way CA calls the exit. There is a workarea dsect and notes from
> CA peppered through the exit and doc saying there is a
want more details.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of scott Ford
Sent: Monday, November 25, 2019 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
David,
It’s the way CA calls the exit. There is a workarea
The OP wants to issue a WTO for diagnostic purposes.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Monday, November 25, 2019 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
I suspect it is the
on behalf of
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 25, 2019 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
I suspect it is the TSS Installation exit. It gets called a lot, has a 100
byte work area, and I suspect you probably don’t
.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
scott Ford
Sent: Monday, November 25, 2019 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Jon,
Absolutely agree, this is the first time I have seen this but not
surprising.
Scott
On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote:
>
>
>> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford <
> dcrayf...@gmail.com> wrote:
>
> > That's interesting! You said the exit wa
> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford
wrote:
> That's interesting! You said the exit was re-entrant so how is it
> obtaining the working storage. If it's doing a GETMAIN why don't you
> just increase the size
> of the storage. Why do you have a constraint
I would like to see the exit doco!
On 2019-11-25 8:46 PM, scott Ford wrote:
David,
It’s the way CA calls the exit. There is a workarea dsect and notes from
CA peppered through the exit and doc saying there is a 100 byte limitation.
Scott
On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote:
Got any doc for that exit?
On 2019-11-25 8:46 PM, scott Ford wrote:
David,
It’s the way CA calls the exit. There is a workarea dsect and notes from
CA peppered through the exit and doc saying there is a 100 byte limitation.
Scott
On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote:
That'
David,
It’s the way CA calls the exit. There is a workarea dsect and notes from
CA peppered through the exit and doc saying there is a 100 byte limitation.
Scott
On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote:
> That's interesting! You said the exit was re-entrant so how is it
> obtaini
That's interesting! You said the exit was re-entrant so how is it
obtaining the working storage. If it's doing a GETMAIN why don't you
just increase the size
of the storage. Why do you have a constraint of 100 bytes?
On 2019-11-25 1:11 AM, scott Ford wrote:
David,
True, sorry misread his repl
David,
True, sorry misread his reply. David my issue is I have limited storage for
variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t
had this experience on a piece of re-entrant code with this limitation.
This was one of the main reasons I asked the question of my colleague
On 2019-11-23 7:07 AM, scott Ford wrote:
Henri,
That’s what ended up doing , thank you, I appreciate any help.
Maybe a bit of a misunderstanding here. I think what Henri was
suggesting was using a UNIX shell that pipes messages to /dev/console
which writes WTOs using the syslogd daemon.
ec
Henri,
That’s what ended up doing , thank you, I appreciate any help.
Scott
On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper
wrote:
> Maybe a bit late. But a plain WTO via an echo to /dev/console not an
> option?
>
> Sent from my wireless iPhone
>
> > On 19 Nov 2019, at 18:52, scott Ford wrote:
>
Maybe a bit late. But a plain WTO via an echo to /dev/console not an option?
Sent from my wireless iPhone
> On 19 Nov 2019, at 18:52, scott Ford wrote:
>
> Bruce, Peter, all:
>
> A big thanks . its much appreciated by this older t-rex.
>
> Scott
>
>> On Tue, Nov 19, 2019 at 3:10 AM Bruce He
Bruce, Peter, all:
A big thanks . its much appreciated by this older t-rex.
Scott
On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson
wrote:
> Hello Scott,
>
> How I do it.
>
> in CSECT copy list form from CONSTANTs section to DSECT working section
> Update message text
> run WTO execute form
>
> in
Hello Scott,
How I do it.
in CSECT copy list form from CONSTANTs section to DSECT working section
Update message text
run WTO execute form
in DSECT
WTO list form map
in Constants
WTO_text WTO list form with text
WTO_length = * - WTO_text
DESCT maps onto your own STORAGE area, thus copying the
t contain the information.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of Steve Smith
> Sent: Tuesday, November 12, 2019 9:30 AM
> To: IBM-MAIN@L
forms.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
scott Ford
Sent: Monday, November 18, 2019 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Peter,
I agree, since I have been around IBM har
Peter,
I agree, since I have been around IBM hardware/software 40+ yrs. My chief
complaint is samples. I came up through the ranks the hardway, OJT (on the
Job Training ), night school
while i was in Operations. So I spend a lot of time digging for examples.
Recently, a good example , I am working
The way information in various manuals , including IBM and CA has changed.
I see it as being structured for the less technical individuals.
Care to provide some examples within the IBM manuals? The presentation of
information in z/OS technical publications is largely unchanged for a very
long
t contain the information.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of Steve Smith
> Sent: Tuesday, November 12, 2019 9:30 AM
> To: IBM-MAIN@LISTSE
ERV.UA.EDU
Subject: Re: WTO
If you need this in black & white, see chapter 1 of the MVS Assembler
Services Reference.
btw, it seems like an "obvious" place to me.
sas
On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote:
>
> FSVO is; that is where the information on the resp
If you need this in black & white, see chapter 1 of the MVS Assembler
Services Reference.
btw, it seems like an "obvious" place to me.
sas
On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote:
>
> FSVO is; that is where the information on the responsibilities of
> user-written subroutines is. P
FSVO is; that is where the information on the responsibilities of
user-written subroutines is. Perhaps it was supposed to say that system
services are written to do the same thing, but it doesn't.
It should not need to "say" that. Linkage conventions do not apply only
to interfaces between
Discussion List on behalf of
Peter Relson
Sent: Sunday, November 10, 2019 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Yes it's documented and legit, but it's a change in behaviour over the
last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15,
and STORAGE OBTA
, 2019 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Guys,
Yeah I found it it happens to be another Well known ISV’s exit. But I have
a question in regard to when this exit is called it’s like IRREVX01 , so I
assume (I know ) that the WTO should be re-entrant. We are basically using
it for
On Fri, Nov 8, 2019 at 2:30 PM scott Ford wrote:
> All:
>
> I have a bit of an issue I am trying to resolve in Assembler. We use a
> skeleton exit from another vendor and it has been working fine.
> It is re-entrant and keep seeing normal WTO's , i.e. ; WTO
> 'X',ROUTCDE=11 , are not appeari
Does code written at a time before "high halves existed", or perhaps even
before ARs existed, and depending only on OS behavior documented at
such a time, continue to operate correctly?
I can't think of a case where it wouldn't. Because such code would not
have known anything about AMODE 64 or
to:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Sunday, November 10, 2019 2:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WTO
>
> Guys,
>
> Yeah I found it it happens to be another Well known ISV’s exit. But I have
> a question in regard to when this exit
(with the same subject line)?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of scott Ford
Sent: Sunday, November 10, 2019 2:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Guys,
Yeah I found it it happens to be another
Huh? C ‘tee Tran you’ ‘reentrancy’
On Sun, Nov 10, 2019 at 17:26 John Lock wrote:
> I doubt this is a problem of tee Tran you.
> It’s a question of register contents.
>
> On Sun, Nov 10, 2019 at 17:11 scott Ford wrote:
>
>> Guys,
>>
>> Yeah I found it it happens to be another Well known ISV’
I doubt this is a problem of tee Tran you.
It’s a question of register contents.
On Sun, Nov 10, 2019 at 17:11 scott Ford wrote:
> Guys,
>
> Yeah I found it it happens to be another Well known ISV’s exit. But I have
> a question in regard to when this exit is called it’s like IRREVX01 , so I
> a
Guys,
Yeah I found it it happens to be another Well known ISV’s exit. But I have
a question in regard to when this exit is called it’s like IRREVX01 , so I
assume (I know ) that the WTO should be re-entrant. We are basically using
it for diagnostics if needed. Is my assumption correct on the WTO ?
On Sun, 10 Nov 2019 09:30:30 -0500, Peter Relson wrote:
>
>Yes it's documented and legit, but it's a change in behaviour over the
>last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15,
>and STORAGE OBTAIN did not change the high half of R1.
>
>
>You have no way of knowing if that is
Yes it's documented and legit, but it's a change in behaviour over the
last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15,
and STORAGE OBTAIN did not change the high half of R1.
You have no way of knowing if that is true or not. All that you could
possibly say is that you did no
ussion List on behalf of
Tony Harminc
Sent: Saturday, November 9, 2019 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Sat, 9 Nov 2019 at 15:07, Seymour J Metz wrote:
>
> I would assume that any system macro destroys R15-R1 unless the documentation
> says otherwise.
On Sat, 9 Nov 2019 at 15:07, Seymour J Metz wrote:
>
> I would assume that any system macro destroys R15-R1 unless the documentation
> says otherwise. In the case of WTO, the documentation decribes the use of all
> three registers. For that matter, the documentation mentions the use of
> AR14-A
A WTO will use R1 as a parameter register. If you need the value in 1 prior to
the WTO then you must sae and restore it.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
scott Ford
Sent: Friday
/~smetz3
From: IBM Mainframe Discussion List on behalf of
Rupert Reynolds
Sent: Friday, November 8, 2019 4:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
Perhaps I misunderstood, but it seems more likely that WTO has changed
registers and affected the
Charles,
I will have to try MCSFLAG= HRDCPY ..
On Sat, Nov 9, 2019 at 11:18 AM Steve Smith wrote:
> iirc (it was decades ago), WTL drops the exact text into the log. None of
> the ~80 bytes of timestamp, flags, job ID, etc. is prefixed. So, WTO is
> better in that you do get all that.
>
> If
iirc (it was decades ago), WTL drops the exact text into the log. None of
the ~80 bytes of timestamp, flags, job ID, etc. is prefixed. So, WTO is
better in that you do get all that.
If WTL suits the purpose though, I don't see much harm in using it.
However, if you have any log post-processing,
On Sat, 9 Nov 2019, at 15:14, Charles Mills wrote:
> Possibly because AT LEAST since z/OS 1.10 (and I think long before that) IBM
> has been saying
>
> Note: IBM recommends you use the WTO macro with the MCSFLAG=HRDCPY parameter
> instead of WTL, because WTO supplies more data than WTL.
What does
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jeremy Nicoll
Sent: Saturday, November 9, 2019 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Sat, 9 Nov 2019, at 13:26, Peter Relson wrote:
> But of course you can configure your system to have even those messages
> sent to sysl
1 - 100 of 187 matches
Mail list logo
