Many people ask me to joint my users list.
Some of them write to me that they do not have deep knowledge in the
area I mention.
Some said that they do not have the knowledge, but will test my
product, other say that they will help me with documentation etc..
So, I felt bad about it.
So, what I am g
At 11:11 -0500 on 07/09/2011, Tom Marchant wrote about Re: Annoyance
with the IEZJSAB macro:
On Fri, 8 Jul 2011 17:39:55 -0400, Robert A. Rosenberg
wrote:
The fact that the contents of R14-R1 not remaining unchanged across a
macro invocation is not the issue. The issue was a USING not
remai
In ,
on 07/04/2011
at 07:54 PM, Chokalingam Thangavelu
said:
>Please let me know what would be the best maintenance method for Z/OS
>and from the below 2 options.
None of the above. More specificly, part of it should be
>1. Receive and apply RSU maintenance
with appropriate aging, but I do
In
,
on 07/08/2011
at 02:54 PM, Sérgio Lima Costa said:
>We need now, transfer this EXEC's for run under TSO .
Watch out for changes in syntax.
>What We need, is execute this comands by operators unde Master
>console of ZOS.
There is no more master console. You should be able to issue any
c
In
,
on 07/08/2011
at 09:10 AM, Skip Robinson said:
>But we're talking about customer generated usermods here:
Not quite; we're talking about a vendor[1] whose documented
customization procedure requires bypassing SMP. The basic problem is
not the UCLIN, it's the need to do a zap for a PROGR
In <4e174c4d.9070...@ync.net>, on 07/08/2011
at 01:28 PM, Rick Fochtman said:
>I've used QSAM to access individual members of a PDS,
I thought I was the only one crazy enough to do that ;-)
>but it's not a practice I'd recommend to the novice.
It's not a practice I'd recommend to a journeym
In , on 07/07/2011
at 09:50 PM, "Robert A. Rosenberg" said:
>You are confusing two issues.
No.
>There is a USING for R1 when the macro was called.
I'm aware of that.
>This USING was destroyed by the macro when it issued its own USING
>without bracketing it with a PUSH/POP.
I see nothing
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mike Schwab
>
> Doesn't the TRanslate and Test instruction set R2 to an address?
Sometimes. :-)
-jc-
--
For IBM-MAIN subscribe / signoff / arc
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of John Weber
>
> I appreciated all of the good and prompt responses. It was really
appreciated. I did try
> 'task' just now with the same result. But this may just be the way
our logic is coded.
>
> Now we are trying
I am running the IBM Debug Tool v11.1 and trying to get Code Coverage to work.
When I run the generated job from the Setup Utility I get the following warning
for all 4 compile samples:
EQACU058W Setup: Listing has no executable statements: no breakpoints inserted
There isn't much informatio
On 7/9/2011 10:46 AM, Paul Gilmartin wrote:
The issue remains consistency. Nearly all system macros leave the USINGs
in effect unchanged regardless that they change and leave changed the
content of associated registers. The macro in question here is anomalous
in modifying the USINGs.
Agreed.
On Sat, 9 Jul 2011 11:11:19 -0500, Tom Marchant
wrote:
>
>If a macro changes, e.g., register 4 (with an appropriate save) and issues
>a USING for register 4, there would be no disagreement. In that case
>PUSH USING/POP USING would be needed.
>
>However, I am not convinced that it would be correc
On Fri, 8 Jul 2011 17:39:55 -0400, Robert A. Rosenberg
wrote:
>The fact that the contents of R14-R1 not remaining unchanged across a
>macro invocation is not the issue. The issue was a USING not
>remaining unchanged across the macro invocation. Since the user is
>restoring R1 after the macro the
When I learned Assembler, I was taught that registers 0,1,14 and 15
could NEVER be expected to remain unchanged accross a macro invokation.
If I may say so, the lesson was a bit incomplete. To be more correct,
c
>the slower cp is the measure and not the faster cp.
I would have said that "the standard CP is the measure and not the
specialty engine" but of course in today's world the two statements end up
the same since the standard CP is the slower one when there is a
difference..
>IMO, the base configu
>When I learned Assembler, I was taught that registers 0,1,14 and 15
>could NEVER be expected to remain unchanged accross a macro invokation.
If I may say so, the lesson was a bit incomplete. To be more correct,
change the word "never" to "not" and add "unless the macro documented
otherwise".
HI,
>>I thank God for everything and I know that everything is happen by God.
>>God helps me all the time and I am sure that also in this time.
>>Even if this event looked to me at first, bad. I know the outcome
>>will be good to me as always,because God beside me.
For sure, the outcome is go
On 9/07/2011 15:42 PM, shai hess wrote:
HI,
I am looking for some people which have deep knowledge in IO, ZOS
internal, TCP and open systems.
This users list will not deal with MFN*** at all.
This group will help me with performance, IO effectiveness, net, IO
internal, MVS internal, value
My brother, please sign me up for your list!
God Bless you and your family!
Richard, Vickie, and Randy Pinion
--- shai.h...@gmail.com wrote:
From: shai hess
To: IBM-MAIN@bama.ua.edu
Subject: New users list with some area experties.
Date: Fri, 8 Jul 2011 22:42:31 -0700
HI,
I am looki
I will be out of the office starting 07/08/2011 and will not return until
07/18/2011.
If you need assistance prior to then please contact Ryan Evans at
216-471-2669.
This communication may contain privileged and/or confidential information. It
is intended solely for the use of the addressee. If
20 matches
Mail list logo
