One of the ways we test our Syzygy automation products is to simply type the
message on the console as if it was a regular command or the entire message we
want to test (we also have a process to do this internally from our product,
but I'm assuming that the OP isn't a customer so doesn't have
On Mon, 21 Aug 2023 12:40:41 -0400, Mark Regan wrote:
>Is there a way to generate WTO messages via a batch job to check message
>suppression? At my last site, where we had NetView, we used a CLIST (or was
&g
Hi Mark,
Another possibility ...
Run DFSMSdss (ADRDSSU)and use the WTO/WTOR Command.
Regards,.
David
On 2023-08-21 12:40, Mark Regan wrote:
Is there a way to generate WTO messages via a batch job to check message
suppression? At my last site, where we had NetView, we used a CLIST
Tony,
I are right about the extra plus sign... I used this trick in the past to
attack the z.
If you want to remove the plus sign, you can write a system rexx exec to
use axrwto.
ITschak
בתאריך יום ב׳, 21 באוג׳ 2023 ב-21:30 מאת Tony Harminc :
> On Mon, 21 Aug 2023 at 12:44, ITschak Mugzach
On Mon, 21 Aug 2023 at 12:44, ITschak Mugzach wrote:
> user TSO SEND command '+IKJX0001I BLA BLA',cn(00) (or the actual name of
> the console at your shop. It is also a tricky way to fool automation
> products...
Those automation products should be set up to check for the leading +
sign. (In
z/VM coming soon *
On Mon, Aug 21, 2023 at 7:41 PM Mark Regan wrote:
> Is there a way to generate WTO messages via a batch job to check message
> suppression? At my last site, where we had NetView, we used a CLIST (or was
> it REXX), to do this.
>
> Regards,
>
> Mark Reg
Is there a way to generate WTO messages via a batch job to check message
suppression? At my last site, where we had NetView, we used a CLIST (or was
it REXX), to do this.
Regards,
Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS
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
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
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 R
[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 WT
] On Behalf
Of Pierre Fichaud
Sent: Tuesday, October 18, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: WTO and IEF170I message
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 SDSF LOG.
But I
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 SDSF LOG.
But I also get an IEF170I message for each WTO no matter the flavor.
IEF170I 3 This is a message
A WTO or WTOR macro
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
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
Peter,
Thank you for the explanation. I understand the Customer anchor table you
mentioned above.
Scott
On Wed, Dec 4, 2019 at 8:18 AM Peter Relson wrote:
> I think that ECVTCTB2 was mentioned at a technical disclosure meeting in
> Pok with the ISVs several years ago.
>
> Regardless, this is
I think that ECVTCTB2 was mentioned at a technical disclosure meeting in
Pok with the ISVs several years ago.
Regardless, this is the wording that I now provide upon "assignment" of a
slot (with nnn, xxx, yyy, zzz filled in) describing what that assignment
"gets you", and it applies to
@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 5:14
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
&g
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
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
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
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
ECVTC
ber 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 n
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
*
@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
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 only
, 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
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 only
@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
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
l Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Rupert Reynolds
> Sent: 30 November 2019 16:40
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] WTO
>
> ahem! I meant to say CVTUSER, a very different field from CVTUSR :-)
>
> On Sat, 30 Nov 20
is.’
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Rupert Reynolds
Sent: 30 November 2019 16:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] WTO
ahem! I meant to say CVTUSER, a very different field from CVTUSR :-)
On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote
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
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
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 other ways
It was decided a WTO would be used at the multiple entry points. The exit
itself is a skeleton passing parameter list and at the point of exit the
parameter list in reg1 was passed in a standard way to the user exit with a
..
L R15,=V(name of exit )
BALR R14,R15
Scott
On Sat, Nov 30, 2019 at 6
Peter,
Mgmt decided we would’ve use a WTO ...standard
Scott
On Sat, Nov 30, 2019 at 5:35 PM Rupert Reynolds wrote:
> 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
> poin
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
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.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,
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
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
. Encrypt like everyone is.'
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter Relson
Sent: 29 November 2019 02:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] WTO
Sigh. Sorry.
I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and
ECVTCTB2
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 /
Of
Peter Relson
Sent: 28 November 2019 14:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] WTO
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
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
>
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
> You can cripple your system if you use a macro that is not valid for every
> environment.
Good point. Is WTO always an SVC? If so, and you can be called running on an
SRB, or certain other situations, then WTO is no good. (If there is a branch
option then you must use it in those situ
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
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
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
above is poor coding in today's environment. Today, I would use
some some of Name/Token to "anchor" a data area.
>
> In the case of WTO, use of MF=L in the CSECT does not keep the code from
> being reentrant if, as you describe later, the only use made of it is to
> initialize
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.
In the case of WTO, use of MF=L in the CSECT does not keep the code from being
t; > Working examples which I can refer to and understand
>
> > (prototype) before I start writing code.
>
> CBTTAPE.ORG has tons of real world code. There is probably a variation on
> your request there but you will need to think creatively to find it. Since
f real world code. There is probably a variation on your
request there but you will need to think creatively to find it. Since you
wanted an exit that issues a WTO then look at IEFACTRT. This implementation
will not work in every exit.
Samples need to be generic with very little risk. A sample WT
gt; 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 100 byte
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 dsect
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
WTO has a lot more overhead than one GETMAIN; if it's legitimate to issue the
WTO in the exit, then it's legitimate to issue the GETMAIN or STORAGE.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf
-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
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
> 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
that pipes messages to /dev/console
which writes WTOs using the syslogd daemon.
echo "hello" > /dev/console
I think your problem was related to writing assembler code with WTO
macros?
Scott
On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper
wrote:
Maybe a bit late. But a plain WT
messages to /dev/console
which writes WTOs using the syslogd daemon.
echo "hello" > /dev/console
I think your problem was related to writing assembler code with WTO
macros?
Scott
On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper
wrote:
Maybe a bit late. But a plain WTO via an
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.
> >>
> &g
that pipes messages to /dev/console
which writes WTOs using the syslogd daemon.
echo "hello" > /dev/console
I think your problem was related to writing assembler code with WTO macros?
Scott
On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper
wrote:
Maybe a bit late. But a plain WTO via an
understanding 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.
>
> echo "hello" > /dev/console
>
> I think your problem was related to writing assembler code with WTO macros?
.
echo "hello" > /dev/console
I think your problem was related to writing assembler code with WTO macros?
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 No
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:
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,
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
>
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
: WTO
Seymour,
The way information in various manuals , including IBM and CA has changed.
I see it as being structured for the less technical individuals.
But thats my opinion ..
Scott
On Tue, Nov 12, 2019 at 1:57 PM Seymour J Metz wrote:
> It's an obvious place, but it doesn't cont
IMHO, as long as IBM takes the position that supplied samples are not
guarantied to be correct, the SRL should explain everything in enough detail
that you don't need to rely on the sample.
In the specific case of WTO, I suggest that you look at the generated code for
various forms
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
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
ain 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@LISTSERV.UA
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 responsibiliti
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.
The C or COBOL expects high halves and ARs to be preserved. The assembler
routine is ignorant of them. It calls a z/OS function which alters some
high
halves. Is there a problem?
I am tending to think not. The z/OS function (hopefully!) does not alter
anything that the modern C or COBOL expects
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
ussion 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 OBTAIN did not chan
, 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
On Mon, Nov 11, 2019 at 8:45 AM Charles Mills wrote:
> Sure, there are lots of solutions (assuming the shop is not mortally
> afraid of touching 1993 assembler code, has a budget and staff to do so,
> and can find the source).
>
> My thought is why would the shop expect a problem? Why would a
expectations (Was "WTO")
On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote:
> > The interesting scenario is the case of the "know something" caller
> > calling a "know nothing" target which in turn calls a "know something"
> > target.
>
On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote:
> > The interesting scenario is the case of the "know something" caller
> > calling a "know nothing" target which in turn calls a "know something"
> > target.
>
> I've been thinking about that one for a couple of days. My scenario is
> this:
>
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
>
on
Sent: Monday, November 11, 2019 5:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
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
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
1 - 100 of 251 matches
Mail list logo
