Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: What's up with WTO? - solved

14 views
Skip to first unread message

Steve Comstock

unread,
Nov 23, 2009, 3:49:14 PM11/23/09
to
Hall, Keven wrote:
> What length value does the assembler generate for:
> mvc Detailmsg,sDetailmsg
>
> Keven Hall | keh...@informatica.com
> Software Operative
> Office: 512-795-6959

Ah! That's got it! Thanks, Keven, and Robert. Once
I added in a length modifier, it works!

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Mark Zelden

unread,
Nov 23, 2009, 3:58:56 PM11/23/09
to
On Mon, 23 Nov 2009 13:46:15 -0700, Steve Comstock
<st...@TRAINERSFRIEND.COM> wrote:

>Hall, Keven wrote:
>> What length value does the assembler generate for:
>> mvc Detailmsg,sDetailmsg
>>
>> Keven Hall | keh...@informatica.com
>> Software Operative
>> Office: 512-795-6959
>
>Ah! That's got it! Thanks, Keven, and Robert. Once
>I added in a length modifier, it works!
>
>--
>

Wow! I didn't know IBM-MAIN even had clairvoyant people monitoring
the list. What a bonus that they understand assembler! :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

Edward Jaffe

unread,
Nov 23, 2009, 5:09:49 PM11/23/09
to
Mark Zelden wrote:
> On Mon, 23 Nov 2009 13:46:15 -0700, Steve Comstock
> <st...@TRAINERSFRIEND.COM> wrote:
>
>> Ah! That's got it! Thanks, Keven, and Robert. Once
>> I added in a length modifier, it works!
>>
> Wow! I didn't know IBM-MAIN even had clairvoyant people monitoring
> the list. What a bonus that they understand assembler! :-)
>

Answered on ASSEMBLER-LIST.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/

Veilleux, Jon L

unread,
Nov 24, 2009, 8:10:01 AM11/24/09
to
That doesn't help us here.....


Jon L. Veilleux
veill...@aetna.com
(860) 636-2683

Answered on ASSEMBLER-LIST.

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

Steve Comstock

unread,
Nov 24, 2009, 8:17:44 AM11/24/09
to
Veilleux, Jon L wrote:
> That doesn't help us here.....

Well, I was just trying to pass the word on, so
no one spent any time on the problem once it was
solved.


>
>
> Jon L. Veilleux
> veill...@aetna.com
> (860) 636-2683
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Monday, November 23, 2009 5:05 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: What's up with WTO? - solved
>
> Mark Zelden wrote:
>> On Mon, 23 Nov 2009 13:46:15 -0700, Steve Comstock
>> <st...@TRAINERSFRIEND.COM> wrote:
>>
>>> Ah! That's got it! Thanks, Keven, and Robert. Once I added in a
>>> length modifier, it works!
>>>
>> Wow! I didn't know IBM-MAIN even had clairvoyant people monitoring
>> the list. What a bonus that they understand assembler! :-)
>>
>
> Answered on ASSEMBLER-LIST.
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 5200 W Century Blvd, Suite 800
> Los Angeles, CA 90045
> 310-338-0400 x318
> edj...@phoenixsoftware.com
> http://www.phoenixsoftware.com/

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Lizette Koehler

unread,
Nov 24, 2009, 8:18:24 AM11/24/09
to
Jon,

A Length was added to the MVC command. Otherwise the default length was
used.
mvc Detailmsg,sDetailmsg

Steve provided a sample program
Here's an even more stripped down version, complete code:


*PROCESS COMPAT(NOCASE,MACROCASE),RENT
sysstate archlvl=2
B34TEST RSECT
B34TEST AMODE 31
B34TEST RMODE ANY
stm 14,12,12(13)
larl 12,DATA
using DATA,12
l 2,0(,1)
GETMAIN R,LV=worksize
xc 0(144,1),0(1)
st 13,4(,1)
lr 13,1
using wareas,13
mvc Oline,sOline
mvc Detailmsg,sDetailmsg <--- Length added here
la 2,Oline
sr 0,0
wto text=(2),routcde=(11),mf=(e,Detailmsg)

lr 1,13
l 0,fsize
l 13,4(13)
freemain r,lv=(0),a=(1)
lm 14,12,12(13)
br 14

data ds 0f
fsize dc a(worksize)

sOline ds 0cl90
dc h'88'
dc c'Input CCSID: '
ds cl5
dc cl3' '
dc c'Generated Base36 tag: '
ds cl3
dc cl3' '
dc c'Returned CCSID based on tag: '
ds cl5
dc cl5' '

sDetailmsg wto text=,routcde=(11),mf=l

ltorg
wareas dsect
save ds 36f'0'

Oline ds 0cl90
dc h'88'
dc c'Input CCSID: '
CP ds cl5
dc cl3' '
dc c'Generated Base36 tag: '
DIGS ds cl3
dc cl3' '
dc c'Returned CCSID based on tag: '
CCSID ds cl5
dc cl5' '

Detailmsg wto text=,routcde=(11),mf=l

worksize equ *-save
END B34TEST

Lizette

Veilleux, Jon L

unread,
Nov 24, 2009, 8:25:27 AM11/24/09
to
Thanks Lizette, I just thought that it would be nice to see some information about how the issue was resolved.

Jon,

sDetailmsg wto text=,routcde=(11),mf=l

Detailmsg wto text=,routcde=(11),mf=l

Lizette

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

----------------------------------------------------------------------

Steve Comstock

unread,
Nov 24, 2009, 8:30:06 AM11/24/09
to
Veilleux, Jon L wrote:
> Thanks Lizette, I just thought that it would be nice to see some information about how the issue was resolved.
>
It was included in the post:

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Mark Zelden

unread,
Nov 24, 2009, 8:44:00 AM11/24/09
to
On Tue, 24 Nov 2009 06:29:09 -0700, Steve Comstock
<st...@TRAINERSFRIEND.COM> wrote:

>Veilleux, Jon L wrote:
>> Thanks Lizette, I just thought that it would be nice to see some
information about how the issue was resolved.
>>
>It was included in the post:
>

I missed the explanation of why something that worked "for ages"
broke? To me, that is just as important or maybe even more important.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Rob Scott

unread,
Nov 24, 2009, 8:56:06 AM11/24/09
to
It worked by pure chance - the OP was "lucky" that the workarea storage was zeroes.

Once the un-initialized storage was dirty - then there was a chance that WTO would complain about invalid bit settings.


Rob Scott
Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Mark Zelden
Sent: 24 November 2009 13:43
To: IBM-...@bama.ua.edu
Subject: Re: What's up with WTO? - solved

Mark Zelden

unread,
Nov 24, 2009, 9:01:41 AM11/24/09
to
On Tue, 24 Nov 2009 08:54:59 -0500, Rob Scott <RSc...@ROCKETSOFTWARE.COM> wrote:

>It worked by pure chance - the OP was "lucky" that the workarea storage was
zeroes.
>
>Once the un-initialized storage was dirty - then there was a chance that
WTO would complain about invalid bit settings.
>

So it's related to the GETMAIN changes that were made?

Steve, was your system running with "VSM USEZOSV1R9RULES(NO)" in
DIAGxx or did it not have the APAR on that changed the behavior the
equivalent of VSM USEZOSV1R9RULES(YES)?

Steve Comstock

unread,
Nov 24, 2009, 9:29:32 AM11/24/09
to
Mark Zelden wrote:
> On Tue, 24 Nov 2009 08:54:59 -0500, Rob Scott <RSc...@ROCKETSOFTWARE.COM> wrote:
>
>> It worked by pure chance - the OP was "lucky" that the workarea storage was
> zeroes.
>> Once the un-initialized storage was dirty - then there was a chance that
> WTO would complain about invalid bit settings.
>
> So it's related to the GETMAIN changes that were made?
>
> Steve, was your system running with "VSM USEZOSV1R9RULES(NO)" in
> DIAGxx or did it not have the APAR on that changed the behavior the
> equivalent of VSM USEZOSV1R9RULES(YES)?
>
> Mark

First, I doubt that GETMAIN changes were the cause of the
problem. I only did one GETMAIN and then copied the list
forms of various macros; since it was the first GETMAIN
it was almost certainly zeroed out.

The real cause of the problem was not providing an
explicit length value. I went back to the code that
had always worked and saw that there was a length
value there. Somehow my cut and paste and "fix up"
get rid of the length code.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Mark Zelden

unread,
Nov 24, 2009, 9:38:27 AM11/24/09
to
On Tue, 24 Nov 2009 07:26:59 -0700, Steve Comstock
<st...@TRAINERSFRIEND.COM> wrote:

>Mark Zelden wrote:
>> On Tue, 24 Nov 2009 08:54:59 -0500, Rob Scott <RSc...@ROCKETSOFTWARE.COM>
wrote:
>>
>>> It worked by pure chance - the OP was "lucky" that the workarea storage was
>> zeroes.
>>> Once the un-initialized storage was dirty - then there was a chance that
>> WTO would complain about invalid bit settings.
>>
>> So it's related to the GETMAIN changes that were made?
>>
>> Steve, was your system running with "VSM USEZOSV1R9RULES(NO)" in
>> DIAGxx or did it not have the APAR on that changed the behavior the
>> equivalent of VSM USEZOSV1R9RULES(YES)?
>>
>> Mark
>
>First, I doubt that GETMAIN changes were the cause of the
>problem. I only did one GETMAIN and then copied the list
>forms of various macros; since it was the first GETMAIN
>it was almost certainly zeroed out.
>
>The real cause of the problem was not providing an
>explicit length value. I went back to the code that
>had always worked and saw that there was a length
>value there. Somehow my cut and paste and "fix up"
>get rid of the length code.
>
>

LOL. Thanks.

(Steve, please don't take this the wrong way)...

And people wonder why some sysprogs are skeptical when
application programmers and system users come to them with a problem
and say "nothing changed". (I try go by "trust, but verify")

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Bill Fairchild

unread,
Nov 24, 2009, 9:43:45 AM11/24/09
to
When I read the OP, I assumed that no changes had been made to the code that had worked for ages. Sometimes the phrase "has worked for ages" really means "has worked for ages, and any changes which I may have recently made were trivial. But I really don't remember making any changes recently. But I could be wrong." :-)

One should always initialize the entire remote parameter list for any system service. The IBM books that describe Assembler language services say this in the Using the Services section that appears prior to the first service explained in that book. E.g., here is some of the verbiage from the unauthorized Assembler services book:
"1. Use the list form of the macro, which expands to the parameter list. Place the list form in the section of your program where you keep non-executable data, such as program constants. Do not code it in the instruction stream of your program.
2. In the instruction stream, code a GETMAIN or a STORAGE macro to obtain some virtual storage.
3. Code a move character instruction that moves the parameter list from its non-executable position in your program into the virtual storage area that you obtained."

Bill Fairchild

Software Developer

Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA

Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com
Web: www.rocketsoftware.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Steve Comstock
Sent: Tuesday, November 24, 2009 8:27 AM
To: IBM-...@bama.ua.edu
Subject: Re: What's up with WTO? - solved

The real cause of the problem was not providing an
explicit length value. I went back to the code that
had always worked and saw that there was a length
value there. Somehow my cut and paste and "fix up"
get rid of the length code.

-Steve Comstock

Patrick Lyon

unread,
Nov 24, 2009, 9:48:01 AM11/24/09
to
On Tue, 24 Nov 2009 08:36:57 -0600, Mark Zelden
<mark....@ZURICHNA.COM> wrote:

>And people wonder why some sysprogs are skeptical when
>application programmers and system users come to them with a problem
>and say "nothing changed". (I try go by "trust, but verify")


Can I hear an "Amen"?

Steve Comstock

unread,
Nov 24, 2009, 9:49:11 AM11/24/09
to

No, no. You're absolutely right to do that. I do the same. Just
got caught up in some code complexity that I was "sure" was the
problem, not the code that had always worked, so I couldn't see
the obvious. As usual, a second set of eyes set me straight.


>
> Mark
> --
> Mark Zelden

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Edward Jaffe

unread,
Nov 24, 2009, 10:06:52 AM11/24/09
to
Mark Zelden wrote:
> I try go by "trust, but verify"
>

Tru dat! I do the same with customers and developers alike! Sometimes
they take offense. That is, until my detail-oriented approach uncovers
their dumb mistake...

And, ...yes,... I occasionally fall into the trap myself. (Usually, not
because I assumed my changes were trivial or irrelevant, but rather
because I forgot about them entirely from too much multitasking...)

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------

John Kelly

unread,
Nov 24, 2009, 10:37:41 AM11/24/09
to
When defining DSECT entries, I always find it better to let the assembler
figure out lengths,ie use the length of the generated WTO to define the
length DSECT entry

sDetailmsg wto text=,routcde=(11),mf=l
endmsg ds 0H

then
Detailmsg ds cl(endmsg-sDetailmsg)

then you don't need a length in the MVC.


Jack Kelly
202-502-2390 (Office)

From:
Lizette Koehler <star...@MINDSPRING.COM>
To:
IBM-...@bama.ua.edu
Date:
11/24/2009 08:17 AM
Subject:
Re: What's up with WTO? - solved

Sent by:
IBM Mainframe Discussion List <IBM-...@bama.ua.edu>

Edward Jaffe

unread,
Nov 24, 2009, 10:51:31 AM11/24/09
to
John Kelly wrote:
> When defining DSECT entries, I always find it better to let the assembler
> figure out lengths,ie use the length of the generated WTO to define the
> length DSECT entry
>
> sDetailmsg wto text=,routcde=(11),mf=l
> endmsg ds 0H
>
> then
> Detailmsg ds cl(endmsg-sDetailmsg)
>

I usually do this. Same effect with fewer symbols defined...

sDetailMsg wto text=,routcde=(11),mf=l
DetailMsg equ sDetailMsg,*-sDetailMsg

Barbara Nitz

unread,
Nov 25, 2009, 2:02:37 AM11/25/09
to
>It worked by pure chance - the OP was "lucky" that the workarea storage
was zeroes.
>
>Once the un-initialized storage was dirty - then there was a chance that
WTO would complain about invalid bit settings.

Easiest test for this is to turn on dirty getmain - I had a hard time time, too,
to find the reason for the D23 in (really unchanged) code that had been
written by my predecessors!

Just wait for USEZOS19RULES(NO) to be mandatory! Then 'the first getmain'
may or may not get an allzeroes area.

Regards, Barbara Nitz

Peter Relson

unread,
Nov 25, 2009, 11:34:51 AM11/25/09
to
Bill Fairchild wrote

One should always initialize the entire remote parameter list for any
system service. The IBM books that describe Assembler language services
say this in the Using the Services section that appears prior to the first
service explained in that book. E.g., here is some of the verbiage from
the unauthorized Assembler services book:
"1. Use the list form of the macro, which expands to the parameter list.
Place the list form in the section of your program where you keep
non-executable data, such as program constants. Do not code it in the
instruction stream of your program.
2. In the instruction stream, code a GETMAIN or a STORAGE macro to obtain
some virtual storage.
3. Code a move character instruction that moves the parameter list from its
non-executable position in your program into the virtual storage area that
you obtained."

Please note that the next section in this book also applies to this
question. It is entitled "Alternative List Form Macro".
The alternative list form macro does not require, indeed it precludes,
initialization from a "static" form of the macro. These macros fully
initialize on the execute form. Most macro services provided iby the "MVS"
part of z/OS in the past 15-20 years fit into this category. A subset of
these macros also provide a modify form in which case it is the COMPLETE
option of the Modify or Execute form that does the full initialization.

Most "tradtional" list form macros do work OK if the initialization is with
zeroes. But not all. WTO is one that in some cases will not work properly
with an initialized area of all zeroes. And ESTAE is another. They might
complete successfully but you might not get the default options that you
intend. I personally view this as non-optimal implementation way back when,
but that is water under the bridge as it cannot be changed for
compatibility reasons.

Peter Relson
z/OS Core Technology Design

Binyamin Dissen

unread,
Nov 25, 2009, 1:53:04 PM11/25/09
to
On Wed, 25 Nov 2009 11:33:38 -0500 Peter Relson <rel...@US.IBM.COM> wrote:

:>Bill Fairchild wrote

Talking about macros.........

I recently used IEAMSCHD to do an SRB instead of the old fashioned SCHEDULE as
I liked the SYNCH=YES parameter.

It seemed like every parameter was an indirect pointer to the actual data
item, i.e.,

1. EP=(3) or EP=label means that R3 or LABEL points to a word containing the
EP.

2. PARM=(3) or PARM=label means that R3 or LABEL points to a word containing
the PARM address.

3. SYNCHCOMPADDR=label means that LABEL has the address of a pointer to the
completion code field.

So my code has this:

LA R0,COMPCODE
ST R0,@COMPCODE
LA R0,ABENDCODE
ST R0,@ABENDCODE
LA R0,REASONCODE
ST R0,@REASONCODE
ST R3,SRB_EP
ST R4,SRB_PARM
IEAMSCHD EPADDR=SRB_EP,ENV=HOME,PRIORITY=CURRENT, +
PARM=SRB_PARM,SYNCH=YES,SYNCHCOMPADDR=@COMPCODE, +
SYNCHCODEADDR=@ABENDCODE,SYNCHRSNADDR=@REASONCODE, +
MF=(E,OIEAMSCHD,COMPLETE)

instead of the much more logical

IEAMSCHD EPADDR=(R3),ENV=HOME,PRIORITY=CURRENT, +
PARM=(R4),SYNCH=YES,SYNCHCOMPADDR=COMPCODE, +
SYNCHCODEADDR=ABENDCODE,SYNCHRSNADDR=REASONCODE, +
MF=(E,OIEAMSCHD,COMPLETE)

Why? Oh, why?

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

0 new messages