z/OS 2.5 Announcement out yet?

2021-09-30 Thread Richards, Robert B. (CTR) 
I haven't been able to find anything on z/OS 2.5. It is supposed to be out 
today. Has anyone seen it and if so, can you provide me with the link(s).

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

2021-09-30 Thread Ron Wells 
Still wish  OMVS would slowly be DUMPED (not support for the FLAT file system) 
but all the other JUNK

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Frenzel
Sent: Wednesday, September 29, 2021 4:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: EXTERNAL EMAIL: Re: zPDT Learner's Edition

** EXTERNAL EMAIL - USE CAUTION **


It took some days for me to put some thought into this pricing aspect. From a 
guy who is fascinated with the entire Z platform and all the things there to 
discover I am totally going to get the license. As long as IBM decides to make 
it available in Germany, of course.

Now, if I put myself 5 years back when I didn't even know the Mainframe existed 
and someone would have told me to pay $120 to be allowed to install an 
operating system I had never heard of on my computer to work on a weird looking 
screen, be limited by an 80 column wide editing session and that it is very 
difficult to set up a connection with a graphical editor.. I am having a really 
hard time to believe I would have said yes to buying it. (I am being a bit 
ironic here.)

Perhaps for everyone who is part of this group it's a different story. I am 
just doubting that this so called "Learner's Edition" will actually attract new 
people (learner?) to the platform. Maybe this is just a move to lower the 
numbers of not-so-legal installations of z/OS on an emulator and controlling 
it. As a newbie I would not be sold and probably move on with all the other 
technologies I can use free of charge and that are still fun. I understand that 
it won't just be free. For university students, however, it should be free of 
charge. For instance, check out the GitHub Student Developer Pack 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Feducation.github.com%2Fpack&data=04%7C01%7CRon.Wells%40OMF.COM%7C1d27f5b04e4b498a020b08d98393f632%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C637685493799598634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hac%2BPJdGROzcNFX3yUMnd8ZTtfXOo6d%2Bu%2BFE6G0iPK4%3D&reserved=0.
 So much free stuff.
Put zPDT in there and I bet some folks will dig into it and maybe some day end 
up in this mailing list.

Cheers - David

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von 
Jerry Whitteridge
Gesendet: Freitag, 24. September 2021 18:03
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

Agreed - $120 is something affordable by most, and I'm really excited to see 
this coming out

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Friday, September 24, 2021 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Re: zPDT Learner's Edition

On 9/24/21 9:41 AM, Tom Brennan wrote:
> Like Ray, for years I've been advocating something free or nearly free
> with every IBM manager I happen to see.  No effect so far.  If this
> works it could be a big change for future education.

I feel like $120 / year is well within the reach of any student or hobbyist 
that wants to learn.  It's *SIGNIFICANTLY* more approachable than the $5k entry 
point for other options for professionals from IBM.

It seems as if the announcement on IBM's site may have been slightly premature 
(O(weeks)) as it has purportedly been withdrawn and someone else in the 
community has said that it should be available in mid October.

I'm very much looking forward to seeing how this rolls out.  I love the idea of 
having an IBM supported way to run contemporary z/OS along side my well 
seasoned P/390-E.  :-)



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive acce

Re: z/OS 2.5 Announcement out yet?

2021-09-30 Thread Mark Jacobs 
Here's the link;

https://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897/ENUS221-260&appname=USN#sodx

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Thursday, September 30th, 2021 at 8:40 AM, Richards, Robert B. (CTR) 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

> I haven't been able to find anything on z/OS 2.5. It is supposed to be out 
> today. Has anyone seen it and if so, can you provide me with the link(s).
>
> Bob
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS 2.5 Announcement out yet?

2021-09-30 Thread P H 
https://www.ibm.com/common/ssi/cgi-bin/ssialias?appname=skmwww&htmlfid=897%2FENUS5650-ZOS&infotype=DD&subtype=SM&mhsrc=ibmsearch_a&mhq=Z%2Fos%202.5

Get Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Richards, Robert B. (CTR) <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 30, 2021 1:40:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: z/OS 2.5 Announcement out yet?

I haven't been able to find anything on z/OS 2.5. It is supposed to be out 
today. Has anyone seen it and if so, can you provide me with the link(s).

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

requesting IBM DB2 enhancement

2021-09-30 Thread Bill Giannelli 
what is the procedure to request an enhancement for Db2?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: requesting IBM DB2 enhancement

2021-09-30 Thread Bill Johnson 
https://www.ibm.com/developerworks/rfe/execute?use_case=changeRequestLanding
Check wrap. 



Sent from Yahoo Mail for iPhone


On Thursday, September 30, 2021, 9:34 AM, Bill Giannelli 
 wrote:

what is the procedure to request an enhancement for Db2?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

2021-09-30 Thread zMan 
Eh? You want z/OS to remain in its little puddle of uniqueness, unable to
interoperate with the vast majority of the universe, requiring arcane
skills to do the most basic of tasks and thus ensuring its path toward
demise?

On Thu, Sep 30, 2021 at 8:51 AM Ron Wells <
02ebc63ff5ef-dmarc-requ...@listserv.ua.edu> wrote:

> Still wish  OMVS would slowly be DUMPED (not support for the FLAT file
> system) but all the other JUNK
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

2021-09-30 Thread Ron Wells 
Brain washed.
And I mean support for the FLAT file system is fine..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of zMan
Sent: Thursday, September 30, 2021 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

** EXTERNAL EMAIL - USE CAUTION **


Eh? You want z/OS to remain in its little puddle of uniqueness, unable to 
interoperate with the vast majority of the universe, requiring arcane skills to 
do the most basic of tasks and thus ensuring its path toward demise?

On Thu, Sep 30, 2021 at 8:51 AM Ron Wells < 
02ebc63ff5ef-dmarc-requ...@listserv.ua.edu> wrote:

> Still wish  OMVS would slowly be DUMPED (not support for the FLAT file
> system) but all the other JUNK
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

2021-09-30 Thread Paul Gilmartin 
On Thu, 30 Sep 2021 09:46:40 -0400, zMan wrote:

>Eh? You want z/OS to remain in its little puddle of uniqueness, unable to
>interoperate with the vast majority of the universe, requiring arcane
>skills to do the most basic of tasks and thus ensuring its path toward
>demise?
> 
I could enthusiastically support replacing OMVS wth a Linux if it were
coupled to Classic OS as closely as OMVS.  E.g Regina "address ATTCHMVS"
and the catalogued data set collection mounted as a VFS with autoconvetsion
IBM-1047<-->UTF-8.  For:
o Liniux extensions of POSIX utilities.
o Easy porting of FOSS.

What's the merit or flaw of the FLAT file system?

Still wish  EBCDIC would slowly be DUMPED.

>On Thu, Sep 30, 2021 at 8:51 AM Ron Wells <
>02ebc63ff5ef-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Still wish  OMVS would slowly be DUMPED (not support for the FLAT file
>> system) but all the other JUNK

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

2021-09-30 Thread Paul Gilmartin 
On Thu, 30 Sep 2021 00:35:39 -0500, Bruce Hewson wrote:

>My thanks to all who responded, but especially to Bill Schoen for the fscp 
>exec.
>
He's brilliant, dedicated, and generous.  Sometimes he has translated my merest
wishes into funcrtion.

>Although not being permitted to access guthub from office directly, I was able 
>to get a copy of the exec.
> 
That's to prevent your slacking while pretending to be productive.
Sneakernet Rules1

>As to original reason, looking at merging the new IBM z/OS  supplied UNIX 
>configuration into the existing environment programmatically.
>
Ah!  I exaggerated your requirement.  For that, Dr. Crudele's HFSDIRC is 
adequate, perhaps ideal.
But  a point of technique:

"du "dir1" > lsdir1"
"du "dir2" > lsdir2"
leave the lsdir? files cluttered with path parts.

"( cd "dir1" && pwd && du . ) > lsdir1"
"( cd "dir2" && pwd && du . ) > lsdir2"
show relative paths; no such clutter; easier to compare with diff or ISRSUPC
ISRSUPC, but not diff, might be able to strip the clutter with column ranges.

"cd" is a powerful function.  The TSO designers tried to approximate it with
PROFILE PREFIX, but largely missed the mark.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS 2.5 Announcement out yet?

2021-09-30 Thread David Elliot 
Google it. There is a preview published and one or two other documents.
I hope you are not hoping for any surprises.

On Thu, Sep 30, 2021, 7:40 AM Richards, Robert B. (CTR) <
01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

> I haven't been able to find anything on z/OS 2.5. It is supposed to be out
> today. Has anyone seen it and if so, can you provide me with the link(s).
>
> Bob
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS 2.5 Announcement out yet?

2021-09-30 Thread Paul Gilmartin 
On Thu, 30 Sep 2021 12:06:46 -0500, David Elliot  wrote:

>Google it. There is a preview published and one or two other documents.
>I hope you are not hoping for any surprises.
> 
I now see Doc at:



-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Skip Robinson 
90% of execs are run by general users 90% of the time, either explicitly
from 'command line' or implicitly from an ISPF panel. Some of these folks
may be more or less exec savvy, but most just want an exec to perform some
business task with minimal fuss. They don't know or want to know how the
sausage is made. Just add a touch of mustard and move on. My job as a
sysprog is to install exec updates as transparently as possible with little
fanfare. Users are capable of adapting to change, but they have other
issues to deal with. Let's be kind to them.



On Wed, Sep 29, 2021 at 4:42 PM Seymour J Metz  wrote:

> No:
>
> If you know that the procedure being run is a CLIST, you can code
> the CLIST operand. If you know that the procedure being run is a
> REXX exec, you can code the EXEC operand. If you do not code the
> CLIST or EXEC operand on the EXEC command, the EXEC command
> processor examines line 1 of the procedure for the characters
> "REXX" within a comment. (The characters "REXX" can be in
> uppercase, lowercase, or mixed-case.) This is known as the REXX
> exec identifier.  If the EXEC command finds the REXX exec
> identifier, the EXEC command runs the procedure as a REXX exec.
> Otherwise, it runs the procedure as a CLIST.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Skip Robinson [jo.skip.robin...@gmail.com]
> Sent: Wednesday, September 29, 2021 1:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Is that operand required?
>
> On Wed, Sep 29, 2021 at 10:12 AM Seymour J Metz  wrote:
>
> > By directly, do you  mean explicit use of EXEC? There's an operand to
> > distinguish CLIST from REXX.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Skip Robinson 
> > Sent: Wednesday, September 29, 2021 12:42 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I vs. JCL
> >
> > How about invoking a module directly? No SYSPROC is involved here.
> >
> > EX 'dsn(member)'
> >
> > I have no way to test it at the moment.
> >
> > On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
> >
> > > TSO SYSPROC is the only case I know of where /* REXX */ is required.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> > > of Phil Smith III [li...@akphs.com]
> > > Sent: Wednesday, September 29, 2021 10:06 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: PL/I vs. JCL
> > >
> > > Bob Bridges wrote:
> > >
> > > >Purely by the way, but I've never really understood why so many REXX
> > > modules I see start like this:
> > >
> > > >  /* REXX */
> > >
> > > 
> > >
> > >
> > >
> > > I think (a) it's documented that way in some places; (b) Some
> > environments
> > > may even require that; (c) that's how some/many examples have it; and
> (d)
> > > it's bizarre, because these all work in TSO:
> > >
> > > /* Rexx */
> > > /* This rexx program. */
> > >
> > > /* This is (rexx) */
> > >
> > > /* This is not(rexx)s */
> > >
> > > /* Thisisrexxyep */
> > >
> > > but
> > >
> > > /* This is a program */
> > >
> > > does not. So something is parsing the entire first line, looking for
> the
> > > leading "/*" and four letters "rexx" in a row, case-insensitive.
> Bizarre.
> > >
> > >
> > >
> > > Having grown up in VM, I'd never even thought about it, other than
> > knowing
> > > that I needed the word "rexx" in the first line in TSO. (On VM, just
> the
> > > leading "/*" is sufficient.)
> > >
> > > --
> >
> > Skip Robinson
> > 323-715-0595
> >
> >
> --
>
> --

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Seymour J Metz 
Of course; that's why you do the heavy lifting under the covers. But you need 
to deal with the nits so they don't have to.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skip Robinson [jo.skip.robin...@gmail.com]
Sent: Thursday, September 30, 2021 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

90% of execs are run by general users 90% of the time, either explicitly
from 'command line' or implicitly from an ISPF panel. Some of these folks
may be more or less exec savvy, but most just want an exec to perform some
business task with minimal fuss. They don't know or want to know how the
sausage is made. Just add a touch of mustard and move on. My job as a
sysprog is to install exec updates as transparently as possible with little
fanfare. Users are capable of adapting to change, but they have other
issues to deal with. Let's be kind to them.



On Wed, Sep 29, 2021 at 4:42 PM Seymour J Metz  wrote:

> No:
>
> If you know that the procedure being run is a CLIST, you can code
> the CLIST operand. If you know that the procedure being run is a
> REXX exec, you can code the EXEC operand. If you do not code the
> CLIST or EXEC operand on the EXEC command, the EXEC command
> processor examines line 1 of the procedure for the characters
> "REXX" within a comment. (The characters "REXX" can be in
> uppercase, lowercase, or mixed-case.) This is known as the REXX
> exec identifier.  If the EXEC command finds the REXX exec
> identifier, the EXEC command runs the procedure as a REXX exec.
> Otherwise, it runs the procedure as a CLIST.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Skip Robinson [jo.skip.robin...@gmail.com]
> Sent: Wednesday, September 29, 2021 1:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Is that operand required?
>
> On Wed, Sep 29, 2021 at 10:12 AM Seymour J Metz  wrote:
>
> > By directly, do you  mean explicit use of EXEC? There's an operand to
> > distinguish CLIST from REXX.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Skip Robinson 
> > Sent: Wednesday, September 29, 2021 12:42 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I vs. JCL
> >
> > How about invoking a module directly? No SYSPROC is involved here.
> >
> > EX 'dsn(member)'
> >
> > I have no way to test it at the moment.
> >
> > On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
> >
> > > TSO SYSPROC is the only case I know of where /* REXX */ is required.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> > > of Phil Smith III [li...@akphs.com]
> > > Sent: Wednesday, September 29, 2021 10:06 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: PL/I vs. JCL
> > >
> > > Bob Bridges wrote:
> > >
> > > >Purely by the way, but I've never really understood why so many REXX
> > > modules I see start like this:
> > >
> > > >  /* REXX */
> > >
> > > 
> > >
> > >
> > >
> > > I think (a) it's documented that way in some places; (b) Some
> > environments
> > > may even require that; (c) that's how some/many examples have it; and
> (d)
> > > it's bizarre, because these all work in TSO:
> > >
> > > /* Rexx */
> > > /* This rexx program. */
> > >
> > > /* This is (rexx) */
> > >
> > > /* This is not(rexx)s */
> > >
> > > /* Thisisrexxyep */
> > >
> > > but
> > >
> > > /* This is a program */
> > >
> > > does not. So something is parsing the entire first line, looking for
> the
> > > leading "/*" and four letters "rexx" in a row, case-insensitive.
> Bizarre.
> > >
> > >
> > >
> > > Having grown up in VM, I'd never even thought about it, other than
> > knowing
> > > that I needed the word "rexx" in the first line in TSO. (On VM, just
> the
> > > leading "/*" is sufficient.)
> > >
> > > --
> >
> > Skip Robinson
> > 323-715-0595
> >
> >
> --
>
> --

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Bob Bridges 
A number of people have responded but not actually spelled out the reason.  A 
comment in the first line containing "REXX" is required if the module resides 
in a //SYSPROC DD -- and not if it's in the //SYSEXEC DD -- because //SYSPROC 
modules are interpreted by default by the CLIST interpreter and //SYSEXEC by 
the REXX interpreter.  The /* REXX */ marker in a //SYSPROC module gives the 
system a chance to toggle over to REXX.  There is no analogous switch, AFAIK, 
to have //SYSEXEC modules interpreted as CLISTs.

I'm inferring; I don't recall reading exactly this in any documentation.  But 
it makes sense.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Asked during these last weeks who caused the riots and the killing in LA, my 
answer has been direct and simple:  Who is to blame for the riots?  The rioters 
are to blame.  Who is to blame for the killings?  The killers are to blame.  
-Dan Quayle, U.S. Vice President, after the Rodney King riots in LA */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, September 29, 2021 10:22

TSO SYSPROC is the only case I know of where /* REXX */ is required.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 29, 2021 10:07

I think (a) it's documented that way in some places; (b) Some environments may 
even require that; (c) that's how some/many examples have it; and (d) it's 
bizarre, because these all work in TSO:

/* Rexx */
/* This rexx program. */
/* This is (rexx) */
/* This is not(rexx)s */
/* Thisisrexxyep */

but

/* This is a program */

does not. So something is parsing the entire first line, looking for the 
leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Tuesday, September 28, 2021 21:58

The "/* REXX */" part is required only if the REXX exec is to be run from a PDS 
allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
 
SYSPROC is for CLISTs, SYSEXEC is for REXXs.

> --- On 29/09/2021 6:54 am, Bob Bridges wrote:
>> Purely by the way, but I've never really understood why so many REXX 
>> modules I see start like this:
>>
>>/* REXX */
>>/* Module: Name
>>   Author: Bob Bridges the Magnificent
>>   Purpose: Convert ANSI dates to internal format, or whatever. */
>>
>> ...instead of something like this:
>>
>>/* This REXX converts ANSI dates to internal format, or whatever. 
>> */
>>/* Module: Name
>>   Author: Bob Bridges the Magnificent */

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Bob Bridges 
I once wrote an external routine that can break a character string into various 
individual parms and return them on the stack.  It correctly parses strings 
with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly well 
with a string of one-word arguments, and if I don't have to remember what order 
they come in and don’t have to label them, anything more is almost never 
required.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Having your book turned into a movie is like seeing your oxen turned into 
bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

one of the most powerful features of CLIST is the mechanism by which 
parameters/options are passed by the user: positional or keyword, required or 
optional, with system prompting. I once saw a REXX routine that simulated the 
old command/CLIST parm processing. It was very complicated and hardly worth the 
trouble IMHO.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Infoprint Server, duplex option

2021-09-30 Thread Frank Swarbrick 
Does anyone happen to know if non-PSF print jobs (specifically, LPR or IPP) 
support the use of the DUPLEX parameter on the OUTPUT JCL statement?  I've 
tried it with an IP Printway LPR printer definition, but it doesn't seem to 
have any effect.  The documentation leads me to think it might only be 
supported for PSF printers, but it's really not clear.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Skip Robinson 
Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:

> I once wrote an external routine that can break a character string into
> various individual parms and return them on the stack.  It correctly parses
> strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work perfectly
> well with a string of one-word arguments, and if I don't have to remember
> what order they come in and don’t have to label them, anything more is
> almost never required.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Having your book turned into a movie is like seeing your oxen turned
> into bouillon cubes.  -John LeCarré */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> one of the most powerful features of CLIST is the mechanism by which
> parameters/options are passed by the user: positional or keyword, required
> or optional, with system prompting. I once saw a REXX routine that
> simulated the old command/CLIST parm processing. It was very complicated
> and hardly worth the trouble IMHO.
>
>
-- 

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Seymour J Metz 
I tend to use Perl when I need to do complicated parsing of strings. Java, 
Python and Ruby have similar capabilities in that regard.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Thursday, September 30, 2021 7:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I once wrote an external routine that can break a character string into various 
individual parms and return them on the stack.  It correctly parses strings 
with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly well 
with a string of one-word arguments, and if I don't have to remember what order 
they come in and don’t have to label them, anything more is almost never 
required.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Having your book turned into a movie is like seeing your oxen turned into 
bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

one of the most powerful features of CLIST is the mechanism by which 
parameters/options are passed by the user: positional or keyword, required or 
optional, with system prompting. I once saw a REXX routine that simulated the 
old command/CLIST parm processing. It was very complicated and hardly worth the 
trouble IMHO.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Seymour J Metz 
It's spelled out in the documentation for the EXEC command.

SYSEXEC is REXX only.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Thursday, September 30, 2021 5:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

A number of people have responded but not actually spelled out the reason.  A 
comment in the first line containing "REXX" is required if the module resides 
in a //SYSPROC DD -- and not if it's in the //SYSEXEC DD -- because //SYSPROC 
modules are interpreted by default by the CLIST interpreter and //SYSEXEC by 
the REXX interpreter.  The /* REXX */ marker in a //SYSPROC module gives the 
system a chance to toggle over to REXX.  There is no analogous switch, AFAIK, 
to have //SYSEXEC modules interpreted as CLISTs.

I'm inferring; I don't recall reading exactly this in any documentation.  But 
it makes sense.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Asked during these last weeks who caused the riots and the killing in LA, my 
answer has been direct and simple:  Who is to blame for the riots?  The rioters 
are to blame.  Who is to blame for the killings?  The killers are to blame.  
-Dan Quayle, U.S. Vice President, after the Rodney King riots in LA */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, September 29, 2021 10:22

TSO SYSPROC is the only case I know of where /* REXX */ is required.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 29, 2021 10:07

I think (a) it's documented that way in some places; (b) Some environments may 
even require that; (c) that's how some/many examples have it; and (d) it's 
bizarre, because these all work in TSO:

/* Rexx */
/* This rexx program. */
/* This is (rexx) */
/* This is not(rexx)s */
/* Thisisrexxyep */

but

/* This is a program */

does not. So something is parsing the entire first line, looking for the 
leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Tuesday, September 28, 2021 21:58

The "/* REXX */" part is required only if the REXX exec is to be run from a PDS 
allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.

SYSPROC is for CLISTs, SYSEXEC is for REXXs.

> --- On 29/09/2021 6:54 am, Bob Bridges wrote:
>> Purely by the way, but I've never really understood why so many REXX
>> modules I see start like this:
>>
>>/* REXX */
>>/* Module: Name
>>   Author: Bob Bridges the Magnificent
>>   Purpose: Convert ANSI dates to internal format, or whatever. */
>>
>> ...instead of something like this:
>>
>>/* This REXX converts ANSI dates to internal format, or whatever.
>> */
>>/* Module: Name
>>   Author: Bob Bridges the Magnificent */

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

2021-09-30 Thread Tom Brennan 
More than once I coded short CLIST front-ends to ASM programs in order 
to avoid IKJPARS while still doing the input processing you mentioned. 
The clist would poke the results in a single string for the assembler 
program to easily grab by offsets.


On 9/30/2021 7:37 PM, Skip Robinson wrote:

Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:


I once wrote an external routine that can break a character string into
various individual parms and return them on the stack.  It correctly parses
strings with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly
well with a string of one-word arguments, and if I don't have to remember
what order they come in and don’t have to label them, anything more is
almost never required.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Having your book turned into a movie is like seeing your oxen turned
into bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

one of the most powerful features of CLIST is the mechanism by which
parameters/options are passed by the user: positional or keyword, required
or optional, with system prompting. I once saw a REXX routine that
simulated the old command/CLIST parm processing. It was very complicated
and hardly worth the trouble IMHO.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN