Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Art Gutowski
On Fri, 27 Mar 2020 08:30:42 -0400, Kurt Quackenbush wrote: >Kurt Quackenbush -- IBM, SMP/E Development >Chuck Norris never uses CHECK when he applies PTFs. Chuck Norris doesn't need a a Web App to apply PTFs, he just roundhouse kicks them in. Art Gutowski General Motors, LLC arthur.gutow...@g

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Bruce Hewson
Hi, examples using the code I posted. %SYMSUB 'testing &sysname in &sysplex' &'TESTING TSYS IN PLEX40'. READY %SYMSUB 'Foo' READY

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Bruce Hewson
Hello, here is the code:- /*REXX/ Trace 'o' Parse Source opsys calltype execname . /*=

Re: strange python announcement

2020-03-27 Thread Jack J. Woehr
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 is

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Ed Jaffe
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 hard-

Re: strange python announcement

2020-03-27 Thread Adam Jacobvitz
-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 wrote

Re: strange python announcement

2020-03-27 Thread Wayne Bickerdike
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 t

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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, b

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Charles Mills
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 Discussio

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Clark Morris
[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 >th

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Jeremy Nicoll
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 origina

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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 [jn.

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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 f

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Jeremy Nicoll
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 Nic

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Paul Gilmartin
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, REXX

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Jim Mulder
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.

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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

Re: IGGCSI00 and REXX

2020-03-27 Thread ITschak Mugzach
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 caller

Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Marna WALLE
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 Work

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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 behal

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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: IBM-MA

Re: IGGCSI00 and REXX

2020-03-27 Thread Kirk Wolf
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 CatalogSearch(filterKe

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dale R. Smith
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. > > >-- >Shmue

Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Shaffer, Terri
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

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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 _

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dale R. Smith
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. >

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dana Mitchell
foo = SYSNAME . REXXTRY on TSO say 'Foo:' MVSVAR('SYMDEF','foo') Foo:

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dale R. Smith
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 >SYMD

Re: strange python announcement

2020-03-27 Thread Roland Koo
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, Enterpr

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Paul Gilmartin
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. >> >>

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
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 behave

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dale R. Smith
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 B

Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Marna WALLE
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 sys

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Charles Mills
"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 serio

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
> 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 http://mason.g

Re: strange python announcement

2020-03-27 Thread 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 10:

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Dale R. Smith
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 define

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Farley, Peter x23353
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 o

Re: strange python announcement

2020-03-27 Thread Paul Gilmartin
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 w

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Seymour J Metz
> 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:- > &A1. = '01' > &B1. = 'TEST

Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Shaffer, Terri
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 fe

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

2020-03-27 Thread Peter Relson
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 st

Re: z/OS 2.4 Migration manual and z/OSMF usage

2020-03-27 Thread Kurt Quackenbush
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 z

Re: REXX MVSVAR SYMDEF behavoiur

2020-03-27 Thread Jeremy Nicoll
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