Hi,
examples using the code I posted.
%SYMSUB 'testing in '
&'TESTING TSYS IN PLEX40'.
READY
%SYMSUB 'Foo'
READY
Hello,
here is the code:-
/*REXX/
Trace 'o'
Parse Source opsys calltype execname .
On 3/27/20 4:28 PM, Wayne Bickerdike wrote:
What's a nerd to do? LUA, Rexx or Python?
Python. It's moving forward, great module support, easy syntax.
There's no advantage to REXX anymore, as fine a language as it is.
Python is taking over IBM i where I work.
--
Jack J. Woehr # Science
On 3/27/2020 8:35 AM, Farley, Peter x23353 wrote:
Switching to SYSMDUMP for future 64-bit batch application dumps in production
jobs will also involve the Storage and Operations teams at a company, since
provision for storing (and perhaps keeping archives of) SYSMDUMP files for
resolving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Perl!
Sent from ProtonMail mobile
\ Original Message
On Mar 27, 2020, 3:28 PM, Wayne Bickerdike < wayn...@gmail.com> wrote:
>
>
>
> What's a nerd to do? LUA, Rexx or Python?
>
> On Sat, Mar 28, 2020 at 5:08 AM Roland Koo
What's a nerd to do? LUA, Rexx or Python?
On Sat, Mar 28, 2020 at 5:08 AM Roland Koo wrote:
> The focus of this announcement is on IBM's intent to participate in the
> open source community to help establish Python as a strategic programming
> language on z/OS. We will provide more updates as
Code reviews and design reviews are formal processes. The degree of formality
is determined by the organization mandating or running the reviews.
As for the apostrophes around they name, they say that the memory is the second
thing to go. They suppress the search for labels with the same name,
I did not know that.
Hmmm. Neither does the JCL Reference, it appears: "[SYSMDUMP DD] must be
processed by the
interactive problem control system (IPCS) and therefore should not be
directed
to SYSOUT."
Or am I missing the concept?
Charles
-Original Message-
From: IBM Mainframe
[Default] On 27 Mar 2020 08:35:35 -0700, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:
>Peter,
>
>IBM may have made that decision about SYSABEND and SYSUDUMP 20 years ago, and
>perhaps z/OS systems programmers who pay attention have been aware of it since
On Fri, 27 Mar 2020, at 21:17, Seymour J Metz wrote:
> Well, you could do
>
>symvalue = 'MVSVAR'('SYMDEF','SYMNAME')
>
> I doubt that it will pass code review.
What do you mean by "code review"? Informal checks by
colleagues, or something else?
The point though is that in the OP's
Well, you could do
symvalue = 'MVSVAR'('SYMDEF','SYMNAME')
I doubt that it will pass code review.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Jeremy Nicoll
I believe that you will find that there is no load module called MVSVAR, but
that MVSVAR is an entry in one of the external function packages IRXEFMVS or
IRXEFPCK; the nomenclature can be a bit confusing. Note that REXX loads these
during initialization.
Formally, every procedure in REXX is a
On Fri, 27 Mar 2020, at 20:07, Seymour J Metz wrote:
> MVSVAR is not an external functions
If someone was foolish enough to write their own one, perhaps
having it call the built-in MVSVAR() wouldn't it be possible for
an exec to call the local one in preference to the built-in one?
--
Jeremy
On Fri, 27 Mar 2020 20:07:06 +, Seymour J Metz wrote:
>MVSVAR is not an external functions.
>
It's documented as among TSO/E external functions in
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/tsofunc.htm
Is a clarification RCF needed?
>Further,
SYSMDUMPs can be written to SYSOUT, and then, for the ones you want
to look at with IPCS, extracted to a sequential data set. pool. You can
use
a spool file management program (for example, SDSF or EJES) to do the
extraction.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
MVSVAR is not an external functions. Further, REXX functions only return a
single result. Perhaps you're thinking of commands, or of routines designed to
be invoked with CALL.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
Kirk,
the sample exec is equal to the class you are using. What you supplied is
the calling program code snip. With a small change to the exec, (PARSE
UPPER ARG KEY replaces the Say & Pull statements) you can class it as a
function. exactly like you do with Java, and it is much shorter from
HI Terri,
I'm happy you finally got the server up, but sorry to see that you aren't happy
with the new format of the upgrade materials for z/OS! If you'd like, please
email me your entire list, and we can work through them. Some pieces might be
fixed by changing the content of the Upgrade
I know how REXX expressions work. Read the text that I quoted from the manual,
carefully. The text, as I suspected, is wrong.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
As I suspected, the manual is wrong.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Dana Mitchell [mitchd...@gmail.com]
Sent: Friday, March 27, 2020 2:42 PM
To:
Dale,
Respectfully I disagree - CSI is not equally complicated to setup and
process in all languages.
Here's the IBM shipped z/OS java sample that sets up a call:
https://github.com/zsystems/java-samples/blob/master/CatalogSearchSample.java
...
CatalogSearch catSearch = new
On Fri, 27 Mar 2020 18:48:58 +, Seymour J Metz wrote:
>That's the right answer to the wrong question. You removed the apostrophes
>around foo, so the results are irrelevant. Try my code as written and I
>suspect that you will get results that differ from what's in the manual.
>
>
>--
So a few things happened here.
First I had the issue with the Discovery failing stating it could not talk to
my ACWB 2.1 lpar from my driving ACWA 2.3 lpar.
After looking at all the manuals I could not figure out the reason for the
failure, given my understandings in my first email.
This lead
That's the right answer to the wrong question. You removed the apostrophes
around foo, so the results are irrelevant. Try my code as written and I suspect
that you will get results that differ from what's in the manual.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
On Fri, 27 Mar 2020 12:59:44 -0500, Paul Gilmartin wrote:
>But I wonder if a 23:59:59 error is possible if the date changes between
>iterations of the loop?
>
>I raised this question a while ago concerning use of symbols in JCL.
>Peter Relson replied, simply, "Yes". No circumvention suggested.
foo = SYSNAME
. REXXTRY on TSO
say 'Foo:' MVSVAR('SYMDEF','foo')
Foo:
On Fri, 27 Mar 2020 17:42:30 +, Seymour J Metz wrote:
>Even if you accept "the sky's the limit" for undefined behavior, there's still
>the undocumented issue of whether it is permissible to include a leading
>ampersand or a trailing period with the symbol, which is permissible in the
The focus of this announcement is on IBM's intent to participate in the open
source community to help establish Python as a strategic programming language
on z/OS. We will provide more updates as they become available. Stay tuned...
Roland Koo
IBM Program Director, Offering Management,
On Fri, 27 Mar 2020 12:16:50 -0500, Dale R. Smith wrote:
>On Fri, 27 Mar 2020 16:28:30 +, Seymour J Metz wrote:
>
>>> Read the much improved doc in the z/OS V2.4 TSO/E REXX Reference for
>>> MVSVAR(SYMDEF,xxx).
>>
>>That's what I was quoting.
>>
>>> I think everything will be clearer.
>>
Even if you accept "the sky's the limit" for undefined behavior, there's still
the undocumented issue of whether it is permissible to include a leading
ampersand or a trailing period with the symbol, which is permissible in the
SYMDEF statement. Also, I'd like to see whether the following
On Fri, 27 Mar 2020 16:28:30 +, Seymour J Metz wrote:
>> Read the much improved doc in the z/OS V2.4 TSO/E REXX Reference for
>> MVSVAR(SYMDEF,xxx).
>
>That's what I was quoting.
>
>> I think everything will be clearer.
>
>Clear, but it matches neither my expectations nor the output that
Hi Terri,
You re-ran IZUSETUP, not recently right? That was made obsolete way back on
z/OS V2.1 with APAR PI54286 (2016), to move to the "modern" parmlib (IZUPRMxx)
method. I hope you still aren't using that, and don't have the server running
on your z/OS V2.1 system but rather on a higher
"64-bit" has not really been on application programmers' plates until COBOL
6.3.
And yes, debuggers and dumps certainly overlap. I would guess that Compuware
would assert that Abend-AID plays in the debugger space, and it is very much
an alternative to the 3700-page dump.
+1 on the need for
> Read the much improved doc in the z/OS V2.4 TSO/E REXX Reference for
> MVSVAR(SYMDEF,xxx).
That's what I was quoting.
> I think everything will be clearer.
Clear, but it matches neither my expectations nor the output that Bruce Hewson
described.
--
Shmuel (Seymour J.) Metz
How, absent the consent of the Python developers?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 27, 2020
Read the much improved doc in the z/OS V2.4 TSO/E REXX Reference for
MVSVAR(SYMDEF,xxx). I think everything will be clearer.
I wrote a REXX Program a few years ago to extract and display the various
Static and Dynamic System Symbols that are defined in z/OS. I also included
our inhouse
Peter,
IBM may have made that decision about SYSABEND and SYSUDUMP 20 years ago, and
perhaps z/OS systems programmers who pay attention have been aware of it since
then, but as an application programmer during that entire time I never saw that
decision communicated in any form from either IBM
On Fri, 27 Mar 2020 14:00:40 +0800, Timothy Sipples wrote:
>David Crayford wrote:
>>Almost certainly Rockets port of Python with support offered by IBM and
>>Rocket Software doing L2/L3.
>
>Rocket Software is a member of the open source community. If I had written
>that Statement of Direction I
> how Z/OS handles symbol substitution.
The is no "how Z/OS handles symbol substitution.", only how some particular
piece of code in z/OS does it. The way, e.g., REXX, does is is quite different
from what you describe.
Say we have these symbols defined in IEASYM00:-
> = '01'
> = 'TEST
> =
Thanks Kurt!
You magically fixed it.. j/k but now its working.
I started to play around with my configuration yesterday after the failure
message. I actually deleted most everything and reran my IZUSETUP to rebuild
everything.
I was not the one who did the initial install on this a
As Tom Marchant in effect said, the z/OS answer to the question of what to
use for dump analysis of application dumps is SYSMDUMP (or TDUMP). And it
has been for a long time. And yes it takes IPCS to use it. The decision
to leave SYSABEND and SYSUDUMP processing alone with respect to 64-bit
On 3/26/2020 5:45 PM, Shaffer, Terri wrote:
It then immediately fails stating z/OSMF cant talk to the 2.1 lpar, because
there is no IP address under the SYSTEM tab in z/OSMF.
What do you see when you open the Systems tab? Do you see an entry for
all 5 of your sysplex members, including your
On Fri, 27 Mar 2020, at 04:25, Bruce Hewson wrote:
> Guys,
>
> the code receives ...
> The MVSVAR external function provides for this case, so it will
> substitute for any symbols in the text string, thus building a new
> SYMBOL name, repeating until all symbols are resolved, if possible.
Are
David Crayford wrote:
>Almost certainly Rockets port of Python with support offered by IBM and
>Rocket Software doing L2/L3.
Rocket Software is a member of the open source community. If I had written
that Statement of Direction I would have phrased it this way:
"IBM intends to enable Python on
44 matches
Mail list logo
