Re: Heretic alert: I really detest TSO REXX (the language)

[David Crayford]

On 12/05/2018 7:27 AM, Paul Gilmartin wrote:

On Fri, 11 May 2018 10:41:37 -0500, Kirk Wolf wrote:

...
The good:
...

I've seen no mention in this thread of arbitrary precision aritnmetic.
Some would consider GAAP support even more valuable.

Somehow it's not entirely a scripting feature.

What other languages have it?


All modern scripting languages have decimal libraries. Ironically, some 
use the decNumber package written by Mike Cowlishaw.




-- gil

--
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: Heretic alert: I really detest TSO REXX (the language)

[David Crayford]

On 12/05/2018 6:23 AM, Tony Thigpen wrote:

Come comments on other posts:

David Crayford wrote on 05/11/2018 02:22 PM:
> The fact that REXX does not have native support for VSAM
> data sets is a shocking omission.
This is available on s/VSE.



z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.



David Crayford wrote on 05/11/2018 02:22 PM:
> Lack of variable scoping is one of my biggest gripes. It means
> REXX doesn't scale. Of course, you can add "procedure expose"
> to functions but that soon turns into an intractable mess.
I disagree. This sounds more like you are trying to use programming 
habits/methods designed for another language. Any programming 
'language' should be used as it was designed, not as some other 
'language' was designed. Are you trying to make REXX look like Perl, 
Java, PHP or bash?




Not at all! My opinion is based upon 30+ years of using REXX. The 
inability to pass aggregate types (objects) in REXX (stem variables) to 
functions makes it unsuitable for large programs. This is especially 
true for external functions.
REXX also lacks modules or packages so reusing code is hard. The "expose 
stem." construct doesn't cut it IMO. Once the code grows large it takes 
a lot of mental gymnastics to remember what's been exposed. Lexical 
scoping is

an absolute must in modern programming languages.


David Crayford wrote on 05/11/2018 02:28 PM:
> Perl excels at one thing, regular expressions. Its syntax is ugly
> and it suffers from language bloat.
I equate regular expressions with vi. It takes a lot of use to get 
where you can use it without looking things up, and if you get to that 
point, you have lived a hard life. :-)


I have to admit that the parse instruction in REXX is elegant and one of 
it's redeeming features. But it lacks the power of regular expressions. 
I missed regular expressions in REXX so much I wrote a command processor 
[1].
Extending REXX is difficult and requires writing assembler code. In the 
case of my regex API I needed to use CEEPIPI to glue together the 
assembler code and LE C++ code. Extending languages like Python, Ruby, 
Lua, Node.js
is trivial in comparison. But of course the language bindings for those 
languages are written in C/C++, which is ok for me as I know those 
languages.


[1] https://github.com/daveyc/RTK



David Crayford wrote on 05/11/2018 02:30 PM:
> I'm at a loss as to why anybody would use OOREXX on platforms where
> there are a multitude of better languages to chose from. If it's
> because of familiarity coming from z/OS or z/VM then I would
> advise them to take the time to learn something new. Most modern
> scripting languages can be picked up in less then a day.
And the code produced is usually crap for the first 5,000 or 10,000 
lines of code written in a new language. I had rather know a few 
languages well than many languages 'so-so'. Bringing your existing 
skills into play is always a good thing. Bringing your poor skills 
into play for a production code is just stupid. (I am not against 
using your poorer skills for one-off, one-time use code. That is the 
best place to learn new skills.)




But with modern languages you have to write less code. There are 
libraries to do just about everything you can imagine. I was reading 
about the new web services for REXX to create JSON. It really did hammer 
home
just how difficult it is to do things in REXX that is one line of code 
in modern languages. And to install libraries in modern languages you 
use an installer like pip, gem, npm, luarocks which takes care of 
dependencies etc.
It's a cliche but if the only tool you have is a hammer the whole world 
looks like a nail.


After all the cut-n-paste, I noticed that the biggest complainer is 
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and 




I hate Perl and PHP too. I'm not a fan of Ruby either. I don't much like 
C but it's a useful language to know.
I have been accused before on this list of pathologically hating REXX. 
That's not true, I appreciate it for what it's good at. But I have found 
over the years that I prefer other languages. I'm a software developer 
and write

code for a living so having the best tools available is important to me.



Tony Thigpen

--
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: Heretic alert: I really detest TSO REXX (the language)

[Clark Morris]

[Default] On 11 May 2018 16:26:19 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Fri, 11 May 2018 10:41:37 -0500, Kirk Wolf wrote:
>>...
>>The good:
>>...
>I've seen no mention in this thread of arbitrary precision aritnmetic.
>Some would consider GAAP support even more valuable.
>
>Somehow it's not entirely a scripting feature.
>
>What other languages have it?

While they aren't scripting languages, I would assume that COBOL and
PL/1 fit the requirement for supporting GAAP.

Clark Morris
>
>-- gil
>
>--
>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: Heretic alert: I really detest TSO REXX (the language)

[Paul Gilmartin]

On Fri, 11 May 2018 10:41:37 -0500, Kirk Wolf wrote:
>...
>The good:
>...
I've seen no mention in this thread of arbitrary precision aritnmetic.
Some would consider GAAP support even more valuable.

Somehow it's not entirely a scripting feature.

What other languages have it?

-- gil

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

Re: Heretic alert: I really detest TSO REXX (the language)

[Tony Harminc]

On 11 May 2018 at 15:02, Kirk Wolf  wrote:

> Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
> interface for invoking a "command" in an arbitrary scripting language and
> then providing it with a command processing (and/or ISPF) interface?

Yes. This is particularly a problem if you want to run APF authorized
things from within your scripting language environment.

> What if the TSO command interface that handles REXX/CLIST could recognize
> shebangs to support other script processors, which would be local-spawned
> in the TSO address space and be given a TSO Command processing environment?

Well it's almost there, with some annoyances that IBM could fix if
they wanted to. The interface designed to support compiled REXX looks
for a magic string at a fixed position in the first record, and will
then invoke a routine named later in that same record. So it *should*
be possible for the language to not be REXX, if it can get past a few
basic syntax things.

This is described in some pretty good detail in the TSO/E
Customization book. It even has its own chapter (43 currently).

You can see this in (failing) action by creating an "exec" with a
first line like
EXECPROCBADMODUL
where the "EXECPROC" starts in column 5. Then run it and you'll get an
interesting message.

> Who knows, maybe get crazy and allow TSO command/script processing from
> zFS.   With mixed case > 8 characters!

When you say "from zFS", I'm not quite sure what you mean. You want to type
/u/kirk/myscript
and have it look for the shebang and call the appropriate runtime?
Hmmm... I think that could be accomplished with a drop-in modification
to TSO's IKJSCAN. But of course you're going to want it to work from
ISPF and such, so not quite so simple.

Tony H.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 16:45:38 -0500, Paul Edwards  wrote:

>Yes, I agree that it is possible to construct a
>defacto AM64 32-bit program by making the
>compiler generate an unusual z/OS-specific
>module.

I think you could call this a 32:32 segmented
memory model. Especially if you are using
multiple continents.

BFN. Paul.

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

Re: Heretic alert: I really detest TSO REXX (the language)

[Tony Thigpen]

Come comments on other posts:

David Crayford wrote on 05/11/2018 02:22 PM:
> The fact that REXX does not have native support for VSAM
> data sets is a shocking omission.
This is available on s/VSE.

Paul Gilmartin wrote on 05/11/2018 12:25 PM:
>  No sharing variables between EXECs
This is available on s/VM. (If you know what you are doing.) I don't 
know if it will work on s/VSE or z/OS. It's use is considered 
'non-standard' and usually avoided. Because of that, it's not something 
that is obvious in the documentation but once someone shows you how to 
do it, you will say 'why did I not see that'.


Steve Smith wrote on 05/11/2018 01:35 PM:
> REXX is adequate for a lot of things, but the // and % operators
> just make me mad
Every language has it's syntax. Maybe I would have picked something 
else, but it is reasonable.


David Crayford wrote on 05/11/2018 02:22 PM:
> Lack of variable scoping is one of my biggest gripes. It means
> REXX doesn't scale. Of course, you can add "procedure expose"
> to functions but that soon turns into an intractable mess.
I disagree. This sounds more like you are trying to use programming 
habits/methods designed for another language. Any programming 'language' 
should be used as it was designed, not as some other 'language' was 
designed. Are you trying to make REXX look like Perl, Java, PHP or bash?


David Crayford wrote on 05/11/2018 02:28 PM:
> Perl excels at one thing, regular expressions. Its syntax is ugly
> and it suffers from language bloat.
I equate regular expressions with vi. It takes a lot of use to get where 
you can use it without looking things up, and if you get to that point, 
you have lived a hard life. :-)


David Crayford wrote on 05/11/2018 02:30 PM:
> I'm at a loss as to why anybody would use OOREXX on platforms where
> there are a multitude of better languages to chose from. If it's
> because of familiarity coming from z/OS or z/VM then I would
> advise them to take the time to learn something new. Most modern
> scripting languages can be picked up in less then a day.
And the code produced is usually crap for the first 5,000 or 10,000 
lines of code written in a new language. I had rather know a few 
languages well than many languages 'so-so'. Bringing your existing 
skills into play is always a good thing. Bringing your poor skills into 
play for a production code is just stupid. (I am not against using your 
poorer skills for one-off, one-time use code. That is the best place to 
learn new skills.)


After all the cut-n-paste, I noticed that the biggest complainer is 
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and 



Tony Thigpen

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

Re: Sample program for JES dataset read?

[Charles Mills]

Perhaps I am over-complicating it. (I am just thinking; have not written any 
code yet.)

I think I can use BPXWDYN() for that matter.

I am assuming that I can come down to fopen("//DD:ddname");

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Friday, May 11, 2018 1:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sample program for JES dataset read?

The only slightly tricky thing is the dynamic allocation, that that is
pretty straight forward for the primary subsystem.
You can even use  __svc99() in the C library and then fopen("//DD:ddname",
)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, May 11, 2018 at 12:29 PM, Charles Mills  wrote:

> Thanks. Possibly useful. Not sure at first glance if too "SDSF-specific"
> or not.
>
> I would not be writing in Rexx but Rexx serves just fine as a
> "pseudo-code" language.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, May 11, 2018 8:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sample program for JES dataset read?
>
> On Thu, 10 May 2018 17:30:53 -0700, Charles Mills wrote:
>
> >Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
> >looked) - that shows an example of how to allocate and read a JES spool
> >dataset?
> >
> >How to do this, in other words: https://ibm.co/2IbrcGV
> >
> If Rexx is a suitable alternative, look at Rexx examples in the SDSF
> manual.
> The interface does not require TSO: it's equally usable under Unix System
> Services.
>
> The scheme is to drill down through JobID, stepname, procstepname, to
> DD name.  SDSF then allocates a generated DD name to that spool file.
> An example reads from that to EXECIO DISKR (STEM.  I modified it to
> LINKMVS IEBGENER after I overrode SYSUT1 to the name SDSF generated.
>
> -- gil
>
> --
> 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
>

--
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: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 23:42:14 +0200, Bernd Oppolzer  
wrote:

>When a runtime function is called, this function will probably need a
>service which implies AMODE/RMODE 24.

If you are using z/OS, I think you will find all the
services you require are AM31/RM31-clean, no
need to dumb down to AM24/RM24.

I recommend you passively accept whatever
RMODE you are loaded as (ie just check
whatever you are using as a base register),
and use that to determine which AMODE to
step down to.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 23:24:51 +0200, Bernd Oppolzer  
wrote:

>> Note that he achieved this by allocating 4 GiB
>> above the 4 GiB bar, in order to get 2 GiB. While
>> this technique certainly has its merits, it would
>> be easier to write the compiler if IBM simply
>> provided an IARV64 GETSTOR USE2GBTO4GB.
>> Although that wouldn't guarantee a full 2 GiB
>> like he was able to get with his technique.
>
>I don't think that he gets only 2 GiB;

He said that he allocated 4 GiB, with the purpose
of getting a guaranteed 2 GiB that can be aligned
in a manner that addresses with the high bit of a
32 bit register can actually point to valid addresses.

You seem to be proposing a full 4 GiB continent.
That should also work, and may be a superior
way of doing things so long as, as you mentioned,
you can change the compiler to do whatever
you want.

>Back to your original question: a program generated in this
>compatible way could IMO grow up to 4 GB in size, when run in AMODE 64;
>this way you have what you want: a program which can be up to 4 GB in size,
>runs in AMODE 64 and has 4 byte pointers. But no change from IBM is needed.

Yes, I agree that it is possible to construct a
defacto AM64 32-bit program by making the
compiler generate an unusual z/OS-specific
module. But I am after compatibility with
MVS 3.8j so would like a GETMAIN LOC=32
(the LOC=32 will be ignored on MVS 3.8j).

BFN. Paul.

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

Re: GETMAIN LOC=32

[Bernd Oppolzer]

See my other post also; there should be a separation between the 
(address) registers
that have continent information in the upper half and the other that 
have not.

The compiler which generates the code takes care about this.

When a runtime function is called, this function will probably need a 
service which
implies AMODE/RMODE 24. This means that the (Pascal) code will call the 
runtime, which
resides below 16 MB. The details of the parameter passing have to be 
designed;
maybe the Pascal code must be able to access the LOC=24 storage before 
the runtime
call by manipulating certain address registers. Or, it uses the 
remaining registers
(3, 5, 7, 9, 11), which don't contain continent information in the upper 
half by default.

Inside the runtime, the AMODE switch is done.

Kind regards

Bernd



Am 11.05.2018 um 21:14 schrieb Paul Edwards:

Good point. But note that if the application
also uses LOC=24 or LOC=31 storage, that will
need to be in an address register that has
the upper 32 bits as 0.

BFN. Paul.




On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab  wrote:


If you stick with 32 bit arithmatic instructions, it does not use the
upper 32 bits. of each register, so having the upper 32 bits set like
the address register does no harm.

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
 wrote:

What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before. He suggested, if I understood
it correctly, that a large application should run in AM64, but store
internally
only 32 bit pointers; the left half of all registers used as address
registers
containing the same (nonzero) value all  the time ... as long as the current
"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

you need a separation of address registers and arithmetic registers
internally; that is: the compiler has to know all the time which one
out of the 16 general registers is used for what, and it has to do
some housekeeping on this. And: passing control to another
"continent" is somehow complicated.

But imagine what you get for this: no need to change all the pointer
fields from 4 byte to 8 byte. I find this very promising. Every seperately
compiled "unit" should fit into one continent, anyway ...

As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option. At the moment,
even 31 bit would be very nice, because I am still bound to AMODE 24.

Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
on Facebook: https://www.facebook.com/StanfordPascal/
on GitHub: https://github.com/StanfordPascal/Pascal

Kind regards

Bernd





Am 11.05.2018 um 17:48 schrieb John McKown:

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:


Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a
business value needs to be made in order to get support for changes, in
particular radical changes like AM32. "it would be nice" and "but it's so
cool" aren't business rationalizations for the amount of potentially
broken
customer code that would result from the change you propose. In order to
not have to recompile all applications, or maintain strict bounds between
32 bit apps and 64 bit apps like most other 64 bit architectures, I will
gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
bit address space. If your mythical AM32 was invented, applications would
still have to switch back to AM31 before calling other AM31 code that
expects a variable length paramter list. I still fail to see any business
value to IBM's customers in what you are proposing.


The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list" indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have
use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.




Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.


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



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: GETMAIN LOC=32

[Bernd Oppolzer]

Am 11.05.2018 um 19:34 schrieb Paul Edwards:

On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer  
wrote:


What I found most interesting in this whole thread was a suggestion

>from (IIRC) a SAS guy some days before. He suggested, if I understood

it correctly, that a large application should run in AM64, but store
internally
only 32 bit pointers; the left half of all registers used as address
registers
containing the same (nonzero) value all  the time ... as long as the
current
"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

Note that he achieved this by allocating 4 GiB
above the 4 GiB bar, in order to get 2 GiB. While
this technique certainly has its merits, it would
be easier to write the compiler if IBM simply
provided an IARV64 GETSTOR USE2GBTO4GB.
Although that wouldn't guarantee a full 2 GiB
like he was able to get with his technique.


I don't think that he gets only 2 GiB;
because the application uses AMODE 64, all 64 bits take part
of the addressing, and that means that all 32 low bits are part of
the address. Every L and ST of addresses loads only the lower part
of the address from storage to register (or the other way round);
the higher part is already there.

You only have to take care if you do arithmetic with all 64 bits of
a register, which changes the upper half, that you do this
either with a register that is not used for addressing or
that you restore the "continent" in the upper half after this
arithmetic.

A branch to another program unit which resided in another
"continent" has to change all upper halfs of all registers that
are used for addressing, accordingly. If there is a (sort of) convention
that tells what registers are used for addressing, you can keep
the places minimal where "continent information" needs to be saved,
loaded or restored.

For example: I'm not really familiar with the new 64 bit instruction,
but there must be an instruction similar to MVCL, involving two
64 bit address registers and two length registers. In this case, the
even registers (containing the addresses) should have the continent
information, but the odd registers (containing the length) should not.

Maybe this would be a simple convention:

even register numbers have continent information in the left half by
default, and odd registers don't have it. Exceptions for the registers 13,
15 and 1, which have continent information, too - due to their role
in the linkage process.

This would leave the registers 3, 5, 7, 9, 11 as pure "data" registers,
where all 64 bits can be changed freely without thinking about the
continent information in the left half.

A compiler generated code for 31 bit using this sort of convention
could maybe run with AMODE 64, too, if the runtime sets the
continent information correctly before calling the generated code.
So you could have the same code (using 4 byte pointers etc.)
running with AMODE 31 and 64 ... using different initialization
sequences in the two AMODEs.

If I had enough time, it would be great fun to check out if this
concept would really work.

I would like to hear if someone sees any basic problem why this
concept could not work ...




As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option.

If you're generating 64-bit code you may
as well just use 64-bit pointers and produce
a pure 64-bit application?


Yes, but - see above - it would be interesting IMO
to have the same code running in AMODE 31 and AMODE 64
and have only the runtime (or the initialization sequence)
take care of the differences. (If I generate real 64 bit code,
the offsets of structures containing pointers, for example,
change, because all pointers now need 8 bytes ... so the
code is completely different from the 31 bit code).

I don't know yet if this is really possible. But if it is and if it
is done correctly, it should not be slower than "normal" AMODE 64
using 8 byte pointers ... because there is no difference during execution,
except that only the lower half of most pointers is stored and loaded
and the higher half stays the same most of the time.

BTW: even if you do static linkage, your resulting program object
will probably fit into one "continent", so there will be no need to
reload the continent parts of the registers when calling an external
module. Maybe it is possible to limit "cross continent calls" to
very special "dynamic" calls, which are special even at the source level
of the programming language. Same goes for storage allocation;
the normal allocation functions like malloc etc. should retrieve storage
from inside the continent; only very special allocation functions
should be able to allocate storage in new "continents". After all,
4 GB is large ...

Back to your original question: a program 

Re: Sample program for JES dataset read?

[Kirk Wolf]

The only slightly tricky thing is the dynamic allocation, that that is
pretty straight forward for the primary subsystem.
You can even use  __svc99() in the C library and then fopen("//DD:ddname",
)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, May 11, 2018 at 12:29 PM, Charles Mills  wrote:

> Thanks. Possibly useful. Not sure at first glance if too "SDSF-specific"
> or not.
>
> I would not be writing in Rexx but Rexx serves just fine as a
> "pseudo-code" language.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, May 11, 2018 8:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sample program for JES dataset read?
>
> On Thu, 10 May 2018 17:30:53 -0700, Charles Mills wrote:
>
> >Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
> >looked) - that shows an example of how to allocate and read a JES spool
> >dataset?
> >
> >How to do this, in other words: https://ibm.co/2IbrcGV
> >
> If Rexx is a suitable alternative, look at Rexx examples in the SDSF
> manual.
> The interface does not require TSO: it's equally usable under Unix System
> Services.
>
> The scheme is to drill down through JobID, stepname, procstepname, to
> DD name.  SDSF then allocates a generated DD name to that spool file.
> An example reads from that to EXECIO DISKR (STEM.  I modified it to
> LINKMVS IEBGENER after I overrode SYSUT1 to the name SDSF generated.
>
> -- gil
>
> --
> 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
>

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Kirk Wolf]

Here you go John:

DEAR BOSS,
YOU MAY BE A LUDDITE.

SINCERELY,
JOHN MCKOWN

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Seriously, it is fair to say that POSIX and zFS files need better
support in z/OS.  Take BPXBATCH for example (please :-)

On Fri, May 11, 2018 at 8:03 AM, John McKown 
wrote:

> OK, I bet I got your attention on that {grin}.
>
> But, seriously, I am wondering what the "person in the trenches" thinks
> about the increasing use of UNIX files and commands becoming more prevalent
> on z/OS. I am basically asking because my manager absolutely despises UNIX
> files. And hates the current maintenance processes from IBM and CA which
> force him to use it. One of his reasons is the case sensitivity of the UNIX
> file names. Of course, like most people in the world, his mind has been
> corrupted by the case insensitivity of Windows. As well as the very
> prevalent use of space characters in Windows file and directory names. This
> case sensitivity of names may be another reason why new people, likewise
> corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
> might find it minimally interesting. And maybe even quite interesting, if
> IBM would adopt and maintain a port of the GNU infrastructure software.
>
> What I think, and I am likely stupid on this, is that the Apple HFS+
> approach might work. Just like, at present, when you create a zFS
> filesystem, the default for filenames on an HFS+ filesystem are, like
> Windows, case _in_sensitive. However, when an HFS+ filesystem is
> initialized, it can be set as "case sensitive". This is done on a
> filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
> that it can be made case _in_sensitive (reverse default of HFS+). This
> might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
> directory (usually /u) under automount and set the parameters so that when
> automount creates & initializes a ${HOME} directory, it is
> case-insensitive. And, of course, they should be a way to "flip the switch"
> back an forth between case sensitivity and case insensitivity. Of course,
> the "make insensitive" conversion will need to check & abort if there two
> names in the same directory which are equivalent when case is ignored. I
> would think this would be simple; check for possible problems and if none,
> just flip the switch in some sort of "header" data area.  Regardless of
> case sensitivity or insensitivity, it should be case preserving, like
> Windows.
>
> I know the response from both IBM and CA is/will be basically "suck it up,
> maggot!" (to quote a not-so-favorite D.I.)
>
> Oh, well, it is Friday. And, for me, this is almost a reasonable thought.
>
> --
> We all have skeletons in our closet.
> Mine are so old, they have osteoporosis.
>
> Maranatha! <><
> John McKown
>
> --
> 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: GETMAIN LOC=32

[Paul Edwards]

Good point. But note that if the application
also uses LOC=24 or LOC=31 storage, that will
need to be in an address register that has
the upper 32 bits as 0.

BFN. Paul.




On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab  wrote:

>If you stick with 32 bit arithmatic instructions, it does not use the
>upper 32 bits. of each register, so having the upper 32 bits set like
>the address register does no harm.
>
>On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
> wrote:
>> What I found most interesting in this whole thread was a suggestion
>> from (IIRC) a SAS guy some days before. He suggested, if I understood
>> it correctly, that a large application should run in AM64, but store
>> internally
>> only 32 bit pointers; the left half of all registers used as address
>> registers
>> containing the same (nonzero) value all  the time ... as long as the current
>> "continent" (defined by this nonzero value in the left half) is not exited.
>>
>> This could be a pattern for compiler writers, too, IMO, and has some
>> implications:
>>
>> you need a separation of address registers and arithmetic registers
>> internally; that is: the compiler has to know all the time which one
>> out of the 16 general registers is used for what, and it has to do
>> some housekeeping on this. And: passing control to another
>> "continent" is somehow complicated.
>>
>> But imagine what you get for this: no need to change all the pointer
>> fields from 4 byte to 8 byte. I find this very promising. Every seperately
>> compiled "unit" should fit into one continent, anyway ...
>>
>> As you might probably know, I am the maintainer of the New Stanford
>> Pascal compiler; if I ever reach the point where generating 64 bit code
>> gets interesting, I will think more about this option. At the moment,
>> even 31 bit would be very nice, because I am still bound to AMODE 24.
>>
>> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
>> on Facebook: https://www.facebook.com/StanfordPascal/
>> on GitHub: https://github.com/StanfordPascal/Pascal
>>
>> Kind regards
>>
>> Bernd
>>
>>
>>
>>
>>
>> Am 11.05.2018 um 17:48 schrieb John McKown:
>>>
>>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
>>> wdrisc...@rocketsoftware.com> wrote:
>>>
 Paul,
 Unlike Hercules, z/Architecture is part of a business, and, as such, a
 business value needs to be made in order to get support for changes, in
 particular radical changes like AM32. "it would be nice" and "but it's so
 cool" aren't business rationalizations for the amount of potentially
 broken
 customer code that would result from the change you propose. In order to
 not have to recompile all applications, or maintain strict bounds between
 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
 gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
 bit address space. If your mythical AM32 was invented, applications would
 still have to switch back to AM31 before calling other AM31 code that
 expects a variable length paramter list. I still fail to see any business
 value to IBM's customers in what you are proposing.

>>> The real solution is to go back to the 1960s and tell the OS/360
>>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had
>>> used either an initial half(or full) word which indicated how many
>>> addresses were in the list following or, similar to CMS, had indicated the
>>> end-of-list with a fullword of high values (x0), then when the
>>> architecture was extended to "beyond 24 bit addresses", they could have
>>> use
>>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
>>> the
>>> direct result of this "problem" in the design of OS/360. Of course, the
>>> OS/360 design made finding the end-of-list "easier" and did not "waste" a
>>> fullword of storage. I guess back in the day, that was a very big
>>> consideration.
>>>
>>>
>>>
 Wayne Driscoll
 Rocket Software
 Note - All opinions are strictly my own.

>>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>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: GETMAIN LOC=32

[Mike Schwab]

If you stick with 32 bit arithmatic instructions, it does not use the
upper 32 bits. of each register, so having the upper 32 bits set like
the address register does no harm.

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
 wrote:
> What I found most interesting in this whole thread was a suggestion
> from (IIRC) a SAS guy some days before. He suggested, if I understood
> it correctly, that a large application should run in AM64, but store
> internally
> only 32 bit pointers; the left half of all registers used as address
> registers
> containing the same (nonzero) value all  the time ... as long as the current
> "continent" (defined by this nonzero value in the left half) is not exited.
>
> This could be a pattern for compiler writers, too, IMO, and has some
> implications:
>
> you need a separation of address registers and arithmetic registers
> internally; that is: the compiler has to know all the time which one
> out of the 16 general registers is used for what, and it has to do
> some housekeeping on this. And: passing control to another
> "continent" is somehow complicated.
>
> But imagine what you get for this: no need to change all the pointer
> fields from 4 byte to 8 byte. I find this very promising. Every seperately
> compiled "unit" should fit into one continent, anyway ...
>
> As you might probably know, I am the maintainer of the New Stanford
> Pascal compiler; if I ever reach the point where generating 64 bit code
> gets interesting, I will think more about this option. At the moment,
> even 31 bit would be very nice, because I am still bound to AMODE 24.
>
> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
> on Facebook: https://www.facebook.com/StanfordPascal/
> on GitHub: https://github.com/StanfordPascal/Pascal
>
> Kind regards
>
> Bernd
>
>
>
>
>
> Am 11.05.2018 um 17:48 schrieb John McKown:
>>
>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
>> wdrisc...@rocketsoftware.com> wrote:
>>
>>> Paul,
>>> Unlike Hercules, z/Architecture is part of a business, and, as such, a
>>> business value needs to be made in order to get support for changes, in
>>> particular radical changes like AM32. "it would be nice" and "but it's so
>>> cool" aren't business rationalizations for the amount of potentially
>>> broken
>>> customer code that would result from the change you propose. In order to
>>> not have to recompile all applications, or maintain strict bounds between
>>> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
>>> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
>>> bit address space. If your mythical AM32 was invented, applications would
>>> still have to switch back to AM31 before calling other AM31 code that
>>> expects a variable length paramter list. I still fail to see any business
>>> value to IBM's customers in what you are proposing.
>>>
>> The real solution is to go back to the 1960s and tell the OS/360
>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had
>> used either an initial half(or full) word which indicated how many
>> addresses were in the list following or, similar to CMS, had indicated the
>> end-of-list with a fullword of high values (x0), then when the
>> architecture was extended to "beyond 24 bit addresses", they could have
>> use
>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
>> the
>> direct result of this "problem" in the design of OS/360. Of course, the
>> OS/360 design made finding the end-of-list "easier" and did not "waste" a
>> fullword of storage. I guess back in the day, that was a very big
>> consideration.
>>
>>
>>
>>> Wayne Driscoll
>>> Rocket Software
>>> Note - All opinions are strictly my own.
>>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

[Dyck, Lionel B. (TRA)]

Couldn't you do Address XYZ and then have commands that XYZ understands?

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Friday, May 11, 2018 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

It would be nice to have a choice of scripting languages like on other
platforms.

Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Who knows, maybe get crazy and allow TSO command/script processing from
zFS.   With mixed case > 8 characters!


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, May 11, 2018 at 1:30 PM, David Crayford  wrote:

> I'm at a loss as to why anybody would use OOREXX on platforms where there
> are a multitude of better languages to chose from. If it's because of
> familiarity coming from z/OS or z/VM then I would
> advise them to take the time to learn something new. Most modern scripting
> languages can be picked up in less then a day.
>
>
>
> On 12/05/2018 12:13 AM, Seymour J Metz wrote:
>
>> I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent
>> methods.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of John McKown 
>> Sent: Friday, May 11, 2018 12:07 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: Heretic alert: I really detest TSO REXX (the language)
>>
>> On Fri, May 11, 2018 at 10:41 AM, Kirk Wolf  wrote:
>>
>> Yeah, I said it.  I remember how fond I was of REXX when I first
>>> discovered
>>> it VM/CMS in the 1980s, when big hair and mullets were also great.
>>>
>>> Sure, on the surface it seems like a user friendly scripting language,
>>> but
>>> IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
>>> "BAT".  It does look much easier than the classic Unix shell, but not so
>>> much in practice.
>>>
>>> I recognize that many here have learned it really well and don't have to
>>> think about all of the pitfalls and landmines.   But please don't try to
>>> tell new mainframers who have learned modern scripting languages how nice
>>> it is :-)
>>>
>>> The good:
>>>
>>> - it is on every z/OS system,  and it has a good set of system interfaces
>>> ("environments")
>>> - it does have case-sensitive variable names, which maybe some people
>>> don't
>>> like ;-)
>>>
>>> The bad:
>>>
>>> - a single data type (string)
>>> - limited control flow statements; lack of short-cut boolean expressions
>>> - compound variables - the only data structure you'll ever need?
>>> - weird handling of undefined/omitted variables/args
>>> - variable name scopes?
>>> - packages/namespaces/libraries?
>>> - purports to follow the principle of "least surprise", but I often find
>>> the opposite
>>> - slow (although that really isn't a language criticism)
>>>
>>> ​TSO REXX needs to be allowed to quietly retire to a placid village
>> somewhere; turning the reigns of scripting on TSO & UNIX to "Object
>> Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
>> the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
>> I/O to z/OS data sets. I don't really care for EXECIO, but it is
>> acceptable.
>>
>>
>> ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhO
>> Jdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIA
>> nOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVq
>> hlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI
>> 8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8
>> wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNL
>> cZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-
>> hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/
>> http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm​
>>
>>
>>
>>
>> Kirk Wolf
>>> Dovetailed Technologies
>>> http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdy
>>> rHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoi
>>> NQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39n
>>> poYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gnt
>>> BT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlV
>>> kRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5l
>>> 

Re: Heretic alert: I really detest TSO REXX (the language)

[Kirk Wolf]

It would be nice to have a choice of scripting languages like on other
platforms.

Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Who knows, maybe get crazy and allow TSO command/script processing from
zFS.   With mixed case > 8 characters!


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, May 11, 2018 at 1:30 PM, David Crayford  wrote:

> I'm at a loss as to why anybody would use OOREXX on platforms where there
> are a multitude of better languages to chose from. If it's because of
> familiarity coming from z/OS or z/VM then I would
> advise them to take the time to learn something new. Most modern scripting
> languages can be picked up in less then a day.
>
>
>
> On 12/05/2018 12:13 AM, Seymour J Metz wrote:
>
>> I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent
>> methods.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of John McKown 
>> Sent: Friday, May 11, 2018 12:07 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: Heretic alert: I really detest TSO REXX (the language)
>>
>> On Fri, May 11, 2018 at 10:41 AM, Kirk Wolf  wrote:
>>
>> Yeah, I said it.  I remember how fond I was of REXX when I first
>>> discovered
>>> it VM/CMS in the 1980s, when big hair and mullets were also great.
>>>
>>> Sure, on the surface it seems like a user friendly scripting language,
>>> but
>>> IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
>>> "BAT".  It does look much easier than the classic Unix shell, but not so
>>> much in practice.
>>>
>>> I recognize that many here have learned it really well and don't have to
>>> think about all of the pitfalls and landmines.   But please don't try to
>>> tell new mainframers who have learned modern scripting languages how nice
>>> it is :-)
>>>
>>> The good:
>>>
>>> - it is on every z/OS system,  and it has a good set of system interfaces
>>> ("environments")
>>> - it does have case-sensitive variable names, which maybe some people
>>> don't
>>> like ;-)
>>>
>>> The bad:
>>>
>>> - a single data type (string)
>>> - limited control flow statements; lack of short-cut boolean expressions
>>> - compound variables - the only data structure you'll ever need?
>>> - weird handling of undefined/omitted variables/args
>>> - variable name scopes?
>>> - packages/namespaces/libraries?
>>> - purports to follow the principle of "least surprise", but I often find
>>> the opposite
>>> - slow (although that really isn't a language criticism)
>>>
>>> ​TSO REXX needs to be allowed to quietly retire to a placid village
>> somewhere; turning the reigns of scripting on TSO & UNIX to "Object
>> Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
>> the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
>> I/O to z/OS data sets. I don't really care for EXECIO, but it is
>> acceptable.
>>
>>
>> ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhO
>> Jdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIA
>> nOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVq
>> hlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI
>> 8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8
>> wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNL
>> cZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-
>> hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/
>> http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm​
>>
>>
>>
>>
>> Kirk Wolf
>>> Dovetailed Technologies
>>> http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdy
>>> rHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoi
>>> NQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39n
>>> poYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gnt
>>> BT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlV
>>> kRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5l
>>> RuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4
>>> s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/
>>> http%3A%2F%2Fdovetail.com
>>>
>>>
>>> --
>> We all have skeletons in our closet.
>> Mine are so old, they have osteoporosis.
>>
>> Maranatha! <><
>> John McKown
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> 

Re: GETMAIN LOC=32

[John McKown]

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer  wrote:

> What I found most interesting in this whole thread was a suggestion
> from (IIRC) a SAS guy some days before. He suggested, if I understood
> it correctly, that a large application should run in AM64, but store
> internally
> only 32 bit pointers; the left half of all registers used as address
> registers
> containing the same (nonzero) value all  the time ... as long as the
> current
> "continent" (defined by this nonzero value in the left half) is not exited.
>
> This could be a pattern for compiler writers, too, IMO, and has some
> implications:
>
> you need a separation of address registers and arithmetic registers
> internally; that is: the compiler has to know all the time which one
> out of the 16 general registers is used for what, and it has to do
> some housekeeping on this. And: passing control to another
> "continent" is somehow complicated.
>
> But imagine what you get for this: no need to change all the pointer
> fields from 4 byte to 8 byte. I find this very promising. Every seperately
> compiled "unit" should fit into one continent, anyway ...
>
> As you might probably know, I am the maintainer of the New Stanford
> Pascal compiler; if I ever reach the point where generating 64 bit code
> gets interesting, I will think more about this option. At the moment,
> even 31 bit would be very nice, because I am still bound to AMODE 24.
>
> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
> on Facebook: https://www.facebook.com/StanfordPascal/
> on GitHub: https://github.com/StanfordPascal/Pascal
>
> Kind regards
>
> Bernd
>

​All of this "continent" stuff basically makes me think of "far pointers"
in the segmented (16 bit) Intel era. A far pointer was 32 bit​ field in
which the upper 16 bits was loaded into the ES(?) segment register and the
lower 16 bits into the ? register. The continent methodology is similar
except that each "register" is 32 bits and both together are actually kept
in a single 64 bit register. I am guessing that the continent portion would
use the LFH to be loaded into the high word of the register, and just a
plain L to load the "offset within continent" into the low word of that
register. The "crossing continent" makes me wonder. If one could require
that any single object reside in a single continent, then it might be
possible to use the IARV64 interface to use a "guard" area to cause an
exception if the code tries to overflow from one continent to another.

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: GETMAIN LOC=32

[Alan Altmark]

I've been reading this thread (for too long) and am compelled to ask folks to 
please stop arguing with Paul.  Jim Mulder has rejected Paul's request, and the 
buck stops there as far as I'm concerned.  "Asked and answered, Your Honor."

Paul is entitled to his "want" and all are entitled to their opinion on it, of 
course, but the two sides are clearly not going to achieve a meeting of the 
minds, so unless folks want to talk about it ad nauseum, "Let It Go."

He made his case, it was interesting to think about, and now it's done.

With much appreciation,
Alan Altmark
(speaking for himself)

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

Re: Heretic alert: I really detest TSO REXX (the language)

[David Crayford]

I'm at a loss as to why anybody would use OOREXX on platforms where 
there are a multitude of better languages to chose from. If it's because 
of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern 
scripting languages can be picked up in less then a day.



On 12/05/2018 12:13 AM, Seymour J Metz wrote:

I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.


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


From: IBM Mainframe Discussion List  on behalf of John 
McKown 
Sent: Friday, May 11, 2018 12:07 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

On Fri, May 11, 2018 at 10:41 AM, Kirk Wolf  wrote:


Yeah, I said it.  I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT".  It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines.   But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system,  and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)


​TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.


ref: 
http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhOJdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIAnOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVqhlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNLcZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm​





Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdyrHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoiNQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39npoYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gntBT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlVkRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5lRuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/http%3A%2F%2Fdovetail.com



--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
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


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

Re: Heretic alert: I really detest TSO REXX (the language)

[David Crayford]

I would have to respectfully disagree. PHP is the worst designed 
programming language ever and perl isn't much better. Perl excels at one 
thing, regular expressions. Its syntax is ugly
and it suffers from language bloat. I dislike Ruby because it has 
borrowed many of the "multiple ways to do things" bloat from Perl.


As it's Friday we can all have a laugh at the fact that PHP function 
names were specifically chosen because they were hashed using strlen() 
:) [1]


[1] https://news.ycombinator.com/item?id=6919216

On 12/05/2018 1:35 AM, Steve Smith wrote:

Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl.  And I'm sure that PHP and even that snake language have their
fans.  Maybe IBM should leave script language design to the wider world.

REXX is adequate for a lot of things, but the // and % operators just make
me mad.

​sas​

--
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: Heretic alert: I really detest TSO REXX (the language)

[David Crayford]

That's a fine curated list of the bad points of REXX. If I may add that 
only having one data type, the string, is not the killer feature that 
people laud it to be. As you mentioned, compound varibles
being the only data structure REXX is a problem in todays world. Try 
serializing a REXX array into JSON.


Lack of variable scoping is one of my biggest gripes. It means REXX 
doesn't scale. Of course, you can add "procedure expose" to functions 
but that soon turns into an intractable mess.


I discovered just how slow REXX is when I first started using Lua on 
z/OS. Programs that were running sub-second in Lua were taking 40 
seconds in REXX! Once I ported the Lua I/O standard
library to z/OS it handled all the file systems and data sets types that 
C stdio supports, PS, VSAM, UNIX, hiperspace etc. The fact that REXX 
does not have native support for VSAM data sets
is a shocking omission. And other features like multi-threading are pipe 
dreams in REXX.


On 11/05/2018 11:41 PM, Kirk Wolf wrote:

Yeah, I said it.  I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT".  It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines.   But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system,  and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
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: Heretic alert: I really detest TSO REXX (the language)

[Steve Smith]

Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl.  And I'm sure that PHP and even that snake language have their
fans.  Maybe IBM should leave script language design to the wider world.

REXX is adequate for a lot of things, but the // and % operators just make
me mad.

​sas​

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

Re: [TSO-REXX] Sdsf rexx

[Phil Carlyle]

For additional info on using the LISTDSI command in REXX checkout the following 
link.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/ldsi.htm


PHIL CARLYLE
Information Security | IAM RACF directory services
M: 480-235-2837 | phil.carl...@aexp.com
TEKSystems

“The Universe is made up of Protons, Neutrons, Electrons & Morons!”

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, May 11, 2018 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Sdsf rexx

Yes, you can "read the directory blocks" of a PDSE with BSAM even though they 
do not really exist.

Charles


-Original Message-
From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
Paul Gilmartin
Sent: Friday, May 11, 2018 8:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Sdsf rexx

On Fri, 11 May 2018 13:56:24 +0100, Mike Wawiorko  wrote:

>OUTTRAP with LISTD dsname M  ?
>
>I'm pretty sure others will have better suggestions.
>
There's also an ISPF facility for this.

In days of yore I have allocated a PDS with RECFM=F,LRECL=256,DSORG=PS
and read with Rexx EXECIO and parsed directory blocks.  I believe PDSE
maintains compatibility with this practice.

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


American Express made the following annotations
**
"This message and any attachments are solely for the intended recipient and may 
contain confidential or privileged information. If you are not the intended 
recipient, any disclosure, copying, use, or distribution of the information 
included in this message and any attachments is prohibited. If you have 
received this communication in error, please notify us by reply e-mail and 
immediately and permanently delete this message and any attachments. Thank you."

American Express a ajouté le commentaire suivant le Ce courrier et toute pièce 
jointe qu'il contient sont réservés au seul destinataire indiqué et peuvent 
renfermer des 
renseignements confidentiels et privilégiés. Si vous n'êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courrier 
ou de toute pièce jointe est interdite. Si vous avez reçu cette communication 
par erreur, veuillez nous en aviser par courrier et détruire immédiatement le 
courrier et les pièces jointes. Merci.

**


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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer  
wrote:

>What I found most interesting in this whole thread was a suggestion
>from (IIRC) a SAS guy some days before. He suggested, if I understood
>it correctly, that a large application should run in AM64, but store
>internally
>only 32 bit pointers; the left half of all registers used as address
>registers
>containing the same (nonzero) value all  the time ... as long as the
>current
>"continent" (defined by this nonzero value in the left half) is not exited.
>
>This could be a pattern for compiler writers, too, IMO, and has some
>implications:

Note that he achieved this by allocating 4 GiB
above the 4 GiB bar, in order to get 2 GiB. While
this technique certainly has its merits, it would
be easier to write the compiler if IBM simply
provided an IARV64 GETSTOR USE2GBTO4GB.
Although that wouldn't guarantee a full 2 GiB
like he was able to get with his technique.

>As you might probably know, I am the maintainer of the New Stanford
>Pascal compiler; if I ever reach the point where generating 64 bit code
>gets interesting, I will think more about this option.

If you're generating 64-bit code you may
as well just use 64-bit pointers and produce
a pure 64-bit application?

BFN. Paul.

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

Re: GETMAIN LOC=32

[somitcw]

Reading to cure insomnia:

There may be a real reason why Paul's wording of an
RFE "perhaps" "might" "possibly" be a non-started?

The requests had no suggestions for 32-bit programs.
Non-U.S. based Paul just has issues with English.
There were no suggestions for AMODE 32.
Non-U.S. based Paul just has issues with English.
There is no issue with non-AMODE 64 parameter lists.
There is no issue with writing or rewriting code.
The wild tangents dreamed up to claim why
GETMAIN LOC=2GB.to.4GB-1 is an issue are dreamed
up wild tangents.
ELSQA memory fragmentation is a minor inconvenience
for people using the requested feature only.
IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or
JAVA area losing 2GB is sad but I'm not crying.

But there is a real reason why GETMAIN LOC=32 may
have an issue.

Dr. Gene claimed that the reason that IBM dropped
from AMODE 32 to AMODE 31 was because of a typo in
the Principals of Operation for BXH/BXLE.

Translated, even S360-24bit used algebraic 32 bit
addresses for BXH/BXLE to allow negative displacements.
Algebraic indexing from 2GB-1 to 2GB gives the higher
address a negative number so it is lower than the low
address.
There should be logical BXH/BXLE equilavants but are not.
Was IBM switching from AMODE 32 to AMODE 31 better than
just adding logical equivalents for BXH/BXLE ?

Of course, the data area is requested for AMODE 64
programs so using BXH/BXLE in AMODE 31 has no
relavances to the GETMAIN change request.

But I checked the manuals.  See below.
You can skip to the last note which is for the
zArch for BXH/BXHG/BXLE/BXLEG to see the issue.
I had to change the format for exponentiation
because I post in plain text.  Sorry.
Copy/Paste from OCRed .pdf file could also
introduce some errors.  Sorry again.

Of course, Paul will say that all is AMODE 64 with
all 64 bits registers so both switching to AMODE 31
and using BXH/BXLE on the 2GB to 4GB-1 memory
should cause the issue the programmer asked for.
Using the proper AMODE 64 or the proper AMODE 64
instructions BXHG/BXLEG does not have the issue
with 32 bit algebraic values.

I can't fix the problem with Paul calling the using
of addresses from zero to 4GB-1 a 32-bit system.
It's AMODE 64, it works no difference than
GETMAIN LOC=24 or GETMAIN LOC=31 when used by an
AMODE 64 program.  No difference than a 24 bit
address being stored in an 8 byte register.
Yes, the high order 5 bytes are zero but that is
a given.  Can't fix Paul.

A22-6821-0
IBM System/360 Principles of Operation
Really old and not dated
Pages 64 and 65

Branch On Index High
BXH RS
The second operand is added to the first operand, and 
the sum is compared algebraically with the third op-
erand. Subsequently, the sum is placed in the first 
operand location, regardless of whether the branch is 
taken. When the sum is high, the instruction address 
is replaced by the branch address. When the sum is 
low or equal, instruction sequencing proceeds with the 
updated instruction address. 
 The first and the second operands are in the registers 
specified hy Rl and R3. The third operand register ad-
dress is odd and is either one larger than R3 or equal 
to R3. The branch address is determined prior to the 
addition and comparison.
 Overflow caused by the addition is ignored and does
not affect the comparison. Otherwise, the addition and
comparison proceed as in fixed-point arithmetic. All
32 bits of the general registers participate in the opera-
tions, and negative quantities are expressed in two's-
complement notation. When the first and third oper-
and locations coincide, the original register contents
are used as third operand. 
 Condition Code: The code remains unchanged. 
 Program Interruptions: None.
Programming Note 
The name "branch on index high" indicates that one 
of the major purposes of this instruction is the incre-
menting and testing of an index value. The increment 
may be algebraic and of any magnitude.


SA22-7832-10
z/Architecture Principles of Operation
March 2015
Pages 7-39 and 7-40

BRANCH ON INDEX HIGH 
BXH R1,R3,D2(B2) [RS-a]
BXHG R1,R3,D2(B2) [RSY-a]

BRANCH ON INDEX LOW OR EQUAL 
BXLE R1,R3,D2(B2) [RS-a]
BXLEG R1,R3,D2(B2) [RSY-a]

An increment is added to the first operand, and the
sum is compared with a compare value. The result of
the comparison determines whether branching
occurs. Subsequently, the sum is placed at the first-
operand location. The second-operand address is
used as a branch address. The R3 field designates
registers containing the increment and the compare
value. 

For BRANCH ON INDEX HIGH, when the sum is
high, the instruction address in the current PSW is
replaced by the branch address. When the sum is
low or equal, normal instruction sequencing pro-
ceeds with the updated instruction address. 

For BRANCH ON INDEX LOW OR EQUAL, when the
sum is low or equal, the instruction address in the
current PSW is replaced by the branch address.
When the sum is high, normal instruction sequencing
proceeds with the updated 

Re: [TSO-REXX] Sdsf rexx

[Charles Mills]

Yes, you can "read the directory blocks" of a PDSE with BSAM even though they 
do not really exist.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 11, 2018 8:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Sdsf rexx

On Fri, 11 May 2018 13:56:24 +0100, Mike Wawiorko  wrote:

>OUTTRAP with LISTD dsname M  ?
>
>I'm pretty sure others will have better suggestions.
> 
There's also an ISPF facility for this.

In days of yore I have allocated a PDS with RECFM=F,LRECL=256,DSORG=PS
and read with Rexx EXECIO and parsed directory blocks.  I believe PDSE
maintains compatibility with this practice.

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

Re: Sample program for JES dataset read?

[Charles Mills]

Thanks. Possibly useful. Not sure at first glance if too "SDSF-specific" or not.

I would not be writing in Rexx but Rexx serves just fine as a "pseudo-code" 
language.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 11, 2018 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sample program for JES dataset read?

On Thu, 10 May 2018 17:30:53 -0700, Charles Mills wrote:

>Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
>looked) - that shows an example of how to allocate and read a JES spool
>dataset?
>
>How to do this, in other words: https://ibm.co/2IbrcGV
> 
If Rexx is a suitable alternative, look at Rexx examples in the SDSF manual.
The interface does not require TSO: it's equally usable under Unix System
Services.

The scheme is to drill down through JobID, stepname, procstepname, to
DD name.  SDSF then allocates a generated DD name to that spool file.
An example reads from that to EXECIO DISKR (STEM.  I modified it to
LINKMVS IEBGENER after I overrode SYSUT1 to the name SDSF generated.

-- gil

--
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: GETMAIN LOC=32

[Bernd Oppolzer]

What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before. He suggested, if I understood
it correctly, that a large application should run in AM64, but store 
internally
only 32 bit pointers; the left half of all registers used as address 
registers
containing the same (nonzero) value all  the time ... as long as the 
current

"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

you need a separation of address registers and arithmetic registers
internally; that is: the compiler has to know all the time which one
out of the 16 general registers is used for what, and it has to do
some housekeeping on this. And: passing control to another
"continent" is somehow complicated.

But imagine what you get for this: no need to change all the pointer
fields from 4 byte to 8 byte. I find this very promising. Every seperately
compiled "unit" should fit into one continent, anyway ...

As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option. At the moment,
even 31 bit would be very nice, because I am still bound to AMODE 24.

Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
on Facebook: https://www.facebook.com/StanfordPascal/
on GitHub: https://github.com/StanfordPascal/Pascal

Kind regards

Bernd




Am 11.05.2018 um 17:48 schrieb John McKown:

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:


Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a
business value needs to be made in order to get support for changes, in
particular radical changes like AM32. "it would be nice" and "but it's so
cool" aren't business rationalizations for the amount of potentially broken
customer code that would result from the change you propose. In order to
not have to recompile all applications, or maintain strict bounds between
32 bit apps and 64 bit apps like most other 64 bit architectures, I will
gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
bit address space. If your mythical AM32 was invented, applications would
still have to switch back to AM31 before calling other AM31 code that
expects a variable length paramter list. I still fail to see any business
value to IBM's customers in what you are proposing.


​The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list"​ indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.




Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.





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

Re: GETMAIN LOC=32

[somitcw]

I never ran a S/360-32bit system, but
different users logged on to TSS in different modes.
An IPL of the entire computer complex every time
that every user logged on was probably not done.
i.e. It was a bi-modal architecture.
An LPSW or other instruction would have made
more sense.

I also believe, but have no experience, that memory
from 2GB to 4GB-1 was avoided because there were
no logical versions of BXH and BXLE and some
programmers like to index.

- - - old post - - -

Subject: Re: GETMAIN LOC=32
From: Joe Monk 
Date: Fri, 11 May 2018 11:57:19 -0500

"How did that work? Did a high bit in BASR
cause AM32 to be activated?"

No ... the 360-67 had to be IPL'd in extended PSW mode to activate
AM32. Otherwise it was a BC mode PSW machine...

Joe

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

Re: GETMAIN LOC=32

[Joe Monk]

"How did that work? Did a high bit in BASR
cause AM32 to be activated?"

No ... the 360-67 had to be IPL'd in extended PSW mode to activate
AM32. Otherwise it was a BC mode PSW machine...

Joe

On Fri, May 11, 2018 at 5:32 AM, Paul Edwards  wrote:

> On Fri, 11 May 2018 00:59:14 -0700, Glen  wrote:
>
> >As far as I know, IBM did produce a mainframe with 32 bit virtual
> >addressing.
> >
> >There might not be many around, and I don't think Hercules has this
> >mode,
>
> Hercules/380 has been updated to support AM32.
> What I did was provide an option such that any
> request to activate AM31 with BSM instead
> activates AM32. That means that I have to choose
> between AM31 and AM32 - I can't have both. And
> all my AM31 applications also need to be AM32
> capable.
>
> >but the 360/67 has 32 bit virtual addressing, along with BAS and
> >BASR to use it.
>
> How did that work? Did a high bit in BASR
> cause AM32 to be activated?
>
> Thanks. Paul.
>
> --
> 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: Heretic alert: I really detest TSO REXX (the language)

[John McKown]

On Fri, May 11, 2018 at 11:13 AM, Seymour J Metz  wrote:

> I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent
> methods.
>

​I have not reviewed the actual OOREXX source code. If is uses the C
language "fopen()" to open disk files, then it's good. But if it uses the C
language "open()" for disk files; that subroutine does not support z/OS
datasets.​



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

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: Heretic alert: I really detest TSO REXX (the language)

[Paul Gilmartin]

On Fri, 11 May 2018 10:41:37 -0500, Kirk Wolf wrote:
>
>I recognize that many here have learned it really well and don't have to
>think about all of the pitfalls and landmines.   But please don't try to
>tell new mainframers who have learned modern scripting languages how nice
>it is :-)
>
>The good:
>
>- it is on every z/OS system,  and it has a good set of system interfaces
>("environments")
>- it does have case-sensitive variable names, which maybe some people don't
>like ;-)
>
Sort of, or inconsistently.  Simple symbols are case-insensitive; derived names
or compound symbols are case-sensitive.
>
>The bad:
>
>- a single data type (string)
>- limited control flow statements; lack of short-cut boolean expressions
>- compound variables - the only data structure you'll ever need?
>- weird handling of undefined/omitted variables/args
>- variable name scopes?
>- packages/namespaces/libraries?
>- purports to follow the principle of "least surprise", but I often find
>the opposite
>- slow (although that really isn't a language criticism)
>
My list, considerably overlapping yours:

Shortcomings:
No expressions in compound tails
No sharing variables between EXECs
No call by reference
No COPY/INCLUDE/SOURCE facility
No longITERATE/longLEAVE
No instream data facility (here-document)

-- gil

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

Re: Heretic alert: I really detest TSO REXX (the language)

[Seymour J Metz]

Actually, CLIST can do some things that REXX can't, although on balance I'll 
take REXX over CLIST, EXEC or EXCE2.

I find REXX much friendlier than any Unix shell, although bash certainly has 
some things that REXX needs. IBM: why haven't you added all of the ANSI 
extensions to REXX?

See my "Safe REXX" article from the last century.

I'm relying heavily on Perl, because of regexen and CPAN, and there are many 
things that are much cleaner in REXX.

Add to your bad list:

   looks a lot like PL/I, but PL/I habits will get you in trouble. And, no, 
SIGNAL is not a goto and is a booby trap for the unwary.

And, yes, it is long past time for IBM to upgrade TSO REXX to OOREXX, or at 
least ANSI REXX.

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


From: IBM Mainframe Discussion List  on behalf of 
Kirk Wolf 
Sent: Friday, May 11, 2018 11:41 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Heretic alert: I really detest TSO REXX (the language)

Yeah, I said it.  I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT".  It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines.   But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system,  and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1sCovw_caeZCTiKKtwKM6KRqfReM5pqylWtuvk1WwFDPKPskPZj1hu1_JrFVbwdNQfWij5DzJGZ4GVtjiTXmvZJJHbxLgTfQem4eYseB1CJo1utY4r-0e5vb9C6Duqr9ipvP1TNN5Cf1JYJA4Pqw_VOPfp-9h5bJN-nXwm8QMFXoFe3pxze54XYnZAh0bsuT2S0_B0loJk6BL-cnC8QUoyYo2IyZM1iqTrJLeMUxQ3uLO8lpTjvbnaF51EfzDkdp-E4oEnOBN03c0CPFarq_bG9q0ooIn0E7x7dcozCPHAi2V7--SBonkXru9OIaeQcQwciQ7Pkz33s2xUeqv0fN3uGeMe9UBnucjGHZkPwJ7FR9ekbl9Ele2EAYre-rnt-Y2NjrWRDBKjNmUJQEELWilx84BgJh7GJ_ghLn4pmAs7yUz3-93Ux4PuFrABtv_E2dG/http%3A%2F%2Fdovetail.com

--
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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Pew, Curtis G]

On May 11, 2018, at 10:39 AM, John McKown  wrote:
> 
> I appreciate the response so far. I'm really getting the idea that people
> are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic"
> about it.

I don’t know that I’d describe myself as “enthusiastic”, but “resigned” is more 
negative than how I feel. I really appreciate being able to use Unix tools like 
git and make and such in z/OS.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Heretic alert: I really detest TSO REXX (the language)

[Seymour J Metz]

I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.


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


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, May 11, 2018 12:07 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

On Fri, May 11, 2018 at 10:41 AM, Kirk Wolf  wrote:

> Yeah, I said it.  I remember how fond I was of REXX when I first discovered
> it VM/CMS in the 1980s, when big hair and mullets were also great.
>
> Sure, on the surface it seems like a user friendly scripting language, but
> IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
> "BAT".  It does look much easier than the classic Unix shell, but not so
> much in practice.
>
> I recognize that many here have learned it really well and don't have to
> think about all of the pitfalls and landmines.   But please don't try to
> tell new mainframers who have learned modern scripting languages how nice
> it is :-)
>
> The good:
>
> - it is on every z/OS system,  and it has a good set of system interfaces
> ("environments")
> - it does have case-sensitive variable names, which maybe some people don't
> like ;-)
>
> The bad:
>
> - a single data type (string)
> - limited control flow statements; lack of short-cut boolean expressions
> - compound variables - the only data structure you'll ever need?
> - weird handling of undefined/omitted variables/args
> - variable name scopes?
> - packages/namespaces/libraries?
> - purports to follow the principle of "least surprise", but I often find
> the opposite
> - slow (although that really isn't a language criticism)
>

​TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.


ref: 
http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhOJdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIAnOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVqhlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNLcZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm​




>
> Kirk Wolf
> Dovetailed Technologies
> http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdyrHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoiNQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39npoYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gntBT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlVkRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5lRuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/http%3A%2F%2Fdovetail.com
>
>

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
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: Heretic alert: I really detest TSO REXX (the language)

[John McKown]

On Fri, May 11, 2018 at 10:41 AM, Kirk Wolf  wrote:

> Yeah, I said it.  I remember how fond I was of REXX when I first discovered
> it VM/CMS in the 1980s, when big hair and mullets were also great.
>
> Sure, on the surface it seems like a user friendly scripting language, but
> IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
> "BAT".  It does look much easier than the classic Unix shell, but not so
> much in practice.
>
> I recognize that many here have learned it really well and don't have to
> think about all of the pitfalls and landmines.   But please don't try to
> tell new mainframers who have learned modern scripting languages how nice
> it is :-)
>
> The good:
>
> - it is on every z/OS system,  and it has a good set of system interfaces
> ("environments")
> - it does have case-sensitive variable names, which maybe some people don't
> like ;-)
>
> The bad:
>
> - a single data type (string)
> - limited control flow statements; lack of short-cut boolean expressions
> - compound variables - the only data structure you'll ever need?
> - weird handling of undefined/omitted variables/args
> - variable name scopes?
> - packages/namespaces/libraries?
> - purports to follow the principle of "least surprise", but I often find
> the opposite
> - slow (although that really isn't a language criticism)
>

​TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.


ref: http://oorexx.org/docs/rexxref/book1.htm​




>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
>

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Paul Gilmartin]

On Fri, 11 May 2018 11:47:08 -0400, Carmen Vitullo wrote:

>Talking about strange dsn allocations, I worked as a contractor Y2K for state 
>Govmt, after updating TLSM to support OS/390 2.5 one of our agency's support 
>folks told me I broke TLMS because the dataset(s) they use to write to take 
>for DOL is, for example DSN='Sears Roebuck and Co', DISP=(,KEEP),UNIT=CART 
>
>well I said, you can't do that ! that's not a valid datasets name, but we've 
>been creating them for many years, I found out I was very wrong, CA knew 
>better and provided a PTF fix for the issue, embarrassed, ah yup , I was ! 
>
When I was very new to MVS I created several data sets with such names.  
Experimenting, self-training
in the use of apostrophes in JCL.  I left them allocated.

Within a few days, admins descended on me, irritated because their utility for
scratching nonconforming data sets couldn't handle them.  Too nonconforming,
I guess.

DFSMS should make the rules.  Assembler and all higher layers should obey them
and not invent additional restrictions.

-- gil

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 09:53:32 -0500, Paul Edwards  wrote:

>On Fri, 11 May 2018 23:28:16 +1000, Greg Price  
>wrote:
>
>>Yes, you CAN write programs which would work using the same logic in
>>AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking
>>NOBODY HAS. (Specific counterexamples do not invalidate the point - we
>>are talking about the bulk of application software.)
>
>You don't see any value in writing AM-anything
>code into the future? Eventually everything will
>be AM64-clean and you will have a pure AM64
>environment.

At which point ELSQA can be moved to under
the 4 GiB bar instead of the 2 GiB bar? For all
sites that have cleaned up their code to be
AM-anything. Or is it just z/OS that needs to
be AM64-clean?

BFN. Paul.

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

Re: GETMAIN LOC=32

[John McKown]

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:

> Paul,
> Unlike Hercules, z/Architecture is part of a business, and, as such, a
> business value needs to be made in order to get support for changes, in
> particular radical changes like AM32. "it would be nice" and "but it's so
> cool" aren't business rationalizations for the amount of potentially broken
> customer code that would result from the change you propose. In order to
> not have to recompile all applications, or maintain strict bounds between
> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
> bit address space. If your mythical AM32 was invented, applications would
> still have to switch back to AM31 before calling other AM31 code that
> expects a variable length paramter list. I still fail to see any business
> value to IBM's customers in what you are proposing.
>

​The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list"​ indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.



>
> Wayne Driscoll
> Rocket Software
> Note - All opinions are strictly my own.
>


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Carmen Vitullo]

Talking about strange dsn allocations, I worked as a contractor Y2K for state 
Govmt, after updating TLSM to support OS/390 2.5 one of our agency's support 
folks told me I broke TLMS because the dataset(s) they use to write to take for 
DOL is, for example DSN='Sears Roebuck and Co', DISP=(,KEEP),UNIT=CART 


well I said, you can't do that ! that's not a valid datasets name, but we've 
been creating them for many years, I found out I was very wrong, CA knew better 
and provided a PTF fix for the issue, embarrassed, ah yup , I was ! 



Carmen Vitullo 

- Original Message -

From: "John McKown"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, May 11, 2018 10:39:55 AM 
Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the 
Devil? 

On Fri, May 11, 2018 at 9:06 AM, Charles Mills  wrote: 

> Oh for gosh sakes! Every operating system is different. There is no 
> eleventh commandment "filenames shall be 44 uppercase characters" that UNIX 
> violated. Tell him a foolish consistency is the hobgoblin of little minds. 
> Or that the inability to learn new things is a sign of old age. 
> 
> Or point out that z/OS is case-dependent. Don't think so? Try referencing 
> 'sys1.maclib'. 
> 

​Or, if you want to break someone's mind use 

//SYSUT2 DD DSN='' 

On my system (likely because my ID is very powerful), a data set is 
actually created on a volume. So DADSM will accept the DSN. I had to use 
STORCLAS=NONSMS to force non-SMS allocation. If I didn't, SMS would fail 
the allocation (yah!). However, I couldn't get it catalogued. And when 
using JCL to allocate it, I get: 

3 IEF648I INVALID DISP FIELD- KEEP SUBSTITUTED 
3 IGD01008I NULL STORCLAS ASSIGNED 


​I now have a DSN on a non-SMS volume which is not catalogued (which is 
valid). But, although it is displayed by ISPF 3.4, it cannot be used in any 
way that I have found. I get the weird message "Invalid change"​. I guess 
ISPF is uppercasing the DSN and then whining that the values are different. 

Now that I think about it, I remember many years ago, at my first job, they 
were converting from DOS to VS1. The DOS system actually had a DSN on a 
volume named 'WATER MONSTER FILE' (aka Water Master File -- city water 
dept.). And I could "use it" on VS1. But not really, because it was a DOS 
ISAM dataset. 

I appreciate the response so far. I'm really getting the idea that people 
are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic" 
about it. 



> 
> Charles 
> 
> 
-- 
We all have skeletons in our closet. 
Mine are so old, they have osteoporosis. 

Maranatha! <>< 
John McKown 

-- 
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: Sample program for JES dataset read?

[Paul Gilmartin]

On Thu, 10 May 2018 17:30:53 -0700, Charles Mills wrote:

>Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
>looked) - that shows an example of how to allocate and read a JES spool
>dataset?
>
>How to do this, in other words: https://ibm.co/2IbrcGV
> 
If Rexx is a suitable alternative, look at Rexx examples in the SDSF manual.
The interface does not require TSO: it's equally usable under Unix System
Services.

The scheme is to drill down through JobID, stepname, procstepname, to
DD name.  SDSF then allocates a generated DD name to that spool file.
An example reads from that to EXECIO DISKR (STEM.  I modified it to
LINKMVS IEBGENER after I overrode SYSUT1 to the name SDSF generated.

-- gil

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

Heretic alert: I really detest TSO REXX (the language)

[Kirk Wolf]

Yeah, I said it.  I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT".  It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines.   But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system,  and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

On Fri, May 11, 2018 at 10:19 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

>
>
> I hate EBCDIC!  I wish IBM had provided just an EBCDIC kernel and let FOSS
> supply the shell
> and utilities.
>

​NIH. I somewhat understand why IBM did this. First, IBM is very concerned
with support and quality. GNU software is top quality. But IBM would need
to devote resources to supporting it. And, given the license, any fixes
they made to GNU software would need to be returned to GNU and anyone else
"on request". If good (which is pretty much a "given"), it would be
integrated with the base GNU and distributed to all other GNU user for,
horrors!, _FREE_! I am reasonable certain that this causes IBM to totally
reject it. More or less "if it cost us money to write, it should cost you
use." Damn, there goes my cynicism again.​



>
> Woe be unto web developers who code URLs with chaotic cases then try to
> port their
> site to a UNIX Apache server!
>

​Yeah, I know some Windows people who CamelCase in some code, for
readability, and lowercase in the filesystem for "ease of typing". Also,
woe betide those who use Windows file manage to put spaces in the filename.
Many parsers break on spaces (or other white space) and so the code whines
like a 2yr old (or an old sysprog) when some code (usually a line command)
excavates its bowels on it.​



>
> -- gil
>
>

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

On Fri, May 11, 2018 at 9:06 AM, Charles Mills  wrote:

> Oh for gosh sakes! Every operating system is different. There is no
> eleventh commandment "filenames shall be 44 uppercase characters" that UNIX
> violated. Tell him a foolish consistency is the hobgoblin of little minds.
> Or that the inability to learn new things is a sign of old age.
>
> Or point out that z/OS is case-dependent. Don't think so? Try referencing
> 'sys1.maclib'.
>

​Or, if you want to break someone's mind use

//SYSUT2 DD DSN=''

On my system (likely because my ID is very powerful), a data set is
actually created on a volume. So DADSM will accept the DSN. I had to use
STORCLAS=NONSMS to force non-SMS allocation. If I didn't, SMS would fail
the allocation (yah!). However, I couldn't get it catalogued. And when
using JCL to allocate it, I get:

3 IEF648I INVALID DISP FIELD- KEEP SUBSTITUTED
3 IGD01008I NULL STORCLAS ASSIGNED


​I now have a DSN on a non-SMS volume which is not catalogued (which is
valid). But, although it is displayed by ISPF 3.4, it cannot be used in any
way that I have found. I get the weird message "Invalid change"​. I guess
ISPF is uppercasing the DSN and then whining that the values are different.

Now that I think about it, I remember many years ago, at my first job, they
were converting from DOS to VS1. The DOS system actually had a DSN on a
volume named 'WATER MONSTER FILE' (aka Water Master File -- city water
dept.). And I could "use it" on VS1. But not really, because it was a DOS
ISAM dataset.

I appreciate the response so far. I'm really getting the idea that people
are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic"
about it.



>
> Charles
>
>
-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: [TSO-REXX] Sdsf rexx

[Paul Gilmartin]

On Fri, 11 May 2018 13:56:24 +0100, Mike Wawiorko  wrote:

>OUTTRAP with LISTD dsname M  ?
>
>I'm pretty sure others will have better suggestions.
> 
There's also an ISPF facility for this.

In days of yore I have allocated a PDS with RECFM=F,LRECL=256,DSORG=PS
and read with Rexx EXECIO and parsed directory blocks.  I believe PDSE
maintains compatibility with this practice.

>-Original Message-
>From: Barkow, Eileen
>Sent: 11 May 2018 13:42
>
>...
> s there any way to get the member names in a  PDSE with REXX?
>I need to extract the member  names in a PDSE and plug them into a  job stream.

-- gil

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

Re: [TSO-REXX] Sdsf rexx

[Paul Gilmartin]

On Thu, 10 May 2018 23:47:27 -0500, Edward Gould wrote:
>> 
>> Fear of indention is collateral damage of RECFM=FB,80.  When Rexx first came
>> to TSO it came with a GIM that recommended RECFM=VB,LRECL=generous.
>> IBM then ignored its own advice and made SYSPROC FB,80, dragging wiser
>> coders down with it.
>
>This issue long predates Rexx. Someone please correct me but the first 
>conflict came in Netview (no idea of release but it was early even then)
>There also may have been an issue with SPF (early version) We did not jump on 
>that bandwagon .
>Memory says it was Netview though. 
>
When I first encountered SPF panel definitions were RECFM=VB.  I coded some and
modified others.  I experienced conversion anguish when a later release went to
RECFM=FB.

IEBUPDTE is broken.  That doesn't forgive breaking other things to conform to 
its rules.

-- gil

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Paul Gilmartin]

On Fri, 11 May 2018 07:06:11 -0700, Charles Mills wrote:

>Oh for gosh sakes! Every operating system is different. There is no eleventh 
>commandment "filenames shall be 44 uppercase characters" that UNIX violated. 
>Tell him a foolish consistency is the hobgoblin of little minds. Or that the 
>inability to learn new things is a sign of old age.
>
>Or point out that z/OS is case-dependent. Don't think so? Try referencing 
>'sys1.maclib'.
> 
Peter Relson (among others) lectures me that such data set names and member 
names
are "invalid"; GIGO.  If invalid, why does DFSMS allow me to create (but not 
catalog) them?
Limited resources a half-century ago for such error checking is the weakest of 
excuses:
nowadays that error checking could easily be added.  Or z/OS could be made 
case-insensitive.

NTFS *is* case-sensitive.  Cygwin tells me of a bit in Registry that tells 
applications whether to
call the I/O system in a case-sensitive or insensitive manner.  (Also need to 
tweak /etc/fstab
for Cygwin.)  Alas, most applications ignore that setting and use 
case-insensitive.  With Cygwin
I created several files in one directory with names differing only in character 
case.  Cygwin
treats them cleanly.  Explorer displays all with correct names, but when I 
click on one it's
unpredictable which opens.  "dir" displays all correctly: names, sizes, and 
timestamps.  Again,
when I use one in a cmd.exe command it's unpredictable which one is actually 
used.  Cygwin
warns that executable command search is unconditionally case-insensitive.

I hate EBCDIC!  I wish IBM had provided just an EBCDIC kernel and let FOSS 
supply the shell
and utilities.

Woe be unto web developers who code URLs with chaotic cases then try to port 
their
site to a UNIX Apache server!

-- gil

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

PIPES (was Sdsf rexx)

[Dyck, Lionel B. (TRA)]

Check out the RFE for TSO Pipes that currently has 168 votes and is an 
'uncommitted candidate'. It really needs a solid business case for IBM to move 
forward is what I suspect.

If you search the RFE system for Servers and Systems Software and then product 
z/OS this is the TOP RFE by votes with Full ISPF Support for PDSE Member 
Generations a close 2nd.

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: Friday, May 11, 2018 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

Lionel:

You are so right.  That's why it needs to be in the base.

(There are sites that still have it.)

Ok, people!!!  Go out there and rattle some cages!!!  Your boss, your data
center manager, you sales rep., your SHARE rep., your neighbor's dog, and
anyone else you can think of.  (Skip your manager and/or the dog if they
bite.  :-)  )

LET'S GET PIPELINES IN THE Z/OS BASE!!!

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 11:01 AM, Dyck, Lionel B. (TRA) 
wrote:

> Ask your friendly IBM rep, or search the IBM site, and you won't find it.
> It may be there but it isn't obvious and unless it is integrated it won't
> be exploited by ISVs (or IBM).
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> It's already integrated.  It's just not in the z/OS base.  And you have to
> pay extra.
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) <
> lionel.d...@va.gov>
> wrote:
>
> > PIPES - it would be very nice if IBM were to just integrate PIPES into
> > TSO/REXX and then we can move on and make z/OS an even better platform
> for
> > the future.
> >
> > 
> --
> > Lionel B. Dyck (Contractor)  <
> > Mainframe Systems Programmer – RavenTek Solution Partners
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Hobart Spitz
> > Sent: Friday, May 11, 2018 9:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
> >
> > "pipe listpds" dsn "| stem members."
> >
> > OREXXMan
> > JCL is the buggy whip of 21st century computing.
> > We want Pipelines in the z/OS base.
> >
> > On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo 
> > wrote:
> >
> > > outrap with LISTD works well
> > > soemthing like this works well
> > >
> > >
> > >
> > > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > > If X=16 Then Do
> > > If SYSREASON = 9 Then Do
> > > Say '** Data set has been migrated .. Abort'
> > > Exit
> > > End
> > > If SYSREASON = 5 Then Do
> > > Say '** Data set not cataloged .. Abort'
> > > Exit
> > > End
> > > Else Do
> > > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > > Exit
> > > End
> > > End
> > >
> > >
> > > or even LM services ?
> > > a clist example
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > > ISPEXEC CONTROL ERRORS RETURN
> > > CONTROL END(ENDO)
> > > ISPEXEC LMINIT DATASET('') +
> > > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > > SET  =
> > > GETMBR: +
> > > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > > SET  = 
> > > IF  = 0 THEN DO
> > > SET =()
> > > SET =(1:,)
> > > SET =
> > > ISPEXEC VPUT (MEMPGM)...
> > > and so on
> > >
> > >
> > >
> > > Carmen Vitullo
> > >
> > > - Original Message -
> > >
> > > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Sent: Friday, May 11, 2018 7:56:24 AM
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > > OUTTRAP with LISTD dsname M ?
> > >
> > > I'm pretty sure others will have better suggestions.
> > >
> > > Mike Wawiorko
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Barkow, Eileen
> > > Sent: 11 May 2018 13:42
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > >
> > > ...
> > > Is there any way to get the member names in a PDSE with REXX?
> > > I need to extract the member names in a PDSE 

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

On Fri, May 11, 2018 at 9:48 AM, Steve Thompson  wrote:

> I've got an observation you and your boss probably won't like.
>
> Windows is based on CP/M (that is what Microsoft started with). Guess what
> CP/M was based on.
>

​Hum, I used CP/M on a z80 based system back in the day. I don't recall
what it was based upon. I thought it was "new" from Digital Research (Gary
Kindall). I know that it targeted the 8080 architecture.​



>
> Now, here we are 30+ years from M/S and Windows (~ 1983 for first
> release), and they have a lower RAS than does Linux which started after
> them (~1991).
>
> So, perhaps your boss should consider going to Linux Desktops and get away
> from the problems of Windows?
>

​Too bad that the company CIO is a devoted Windows lover who despises any
other platform: Wintel or Death! seems to be his mantra.​



>
> As more and more people go to Linux Desktops, Adobe (and others) would
> have to change their position and go back to supporting their products for
> Linux distros.
>

​I'd love that!​



>
> And then the *nix file structure being case sensitive would stop being a
> problem, because one would get use to it from working with it on a daily
> basis.
>

​Eventually. Unless the big players like RedHat, Canonical, et al. "did an
Apple" and created a filesystem (ext5?) which could be set as "case
insensitive" in order to placate the masses and get market share.​



>
> My biggest problem with *nix (POSIX) on z/OS is the goofy way we have to
> define the files for it.
>

​Hum, would you expand upon that? I don't really have any problems defining
files. Creating a new filesystem is a bit "weird" to me, but that's because
I use the zfsadm command from a "true" (not TSO OMVS) UNIX shell prompt.
The use of JCL and that program which I can never remember is a bit weird.
And needing to enclose the PATH= value in ' marks is a bit strange, but
understandable from the JCL viewpoint.​




>
> Perhaps the MVS side of z/OS needs to learn to get along with FBA and we
> can stop emulating ECKD with FBA, that then emulate FBA to allow POSIX
> (Unix System Services and related file systems) to work on/with z/OS (what
> overhead).


> [FBA boxes seem to be cheaper than the ones that emulate ECKD devices --
> well at least from where I sit.]
>

​ ​YES! +infinity on that.​ The is the barest beginning of that in z/OS
with "z/OS FBA Services" for a 2107 with the zDDB feature.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa800/fbaasm.htm

That gives the conceptual equivalent to using EXCP or XDAP on an
unformatted ECKD device. IBM needs to work on supported "access method"
type facilities. ​I'd start with the "next generation" zFS filesystem being
able to use "z/OS FBA Services". This shouldn't be, conceptually, a big
problem. The current zFS is a VSAM LINEAR dataset. Which is basically a DSN
which is formatted as 4K physical blocks. The DSN is physically allocated
to the ZFS address space. An FBA device on z/OS is "dedicated" to a single
address space, so that should work the same -- the FBA device is dedicated
to the ZFS address space. IBM "just" needs to write an I/O routine which
uses z/OS FBA Services instead of VSAM LINEAR to access it and Bob's your
uncle.



>
> Just my 2 cents.
>
> Regards,
> Steve Thompson
>
>
-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

Lionel:

You are so right.  That's why it needs to be in the base.

(There are sites that still have it.)

Ok, people!!!  Go out there and rattle some cages!!!  Your boss, your data
center manager, you sales rep., your SHARE rep., your neighbor's dog, and
anyone else you can think of.  (Skip your manager and/or the dog if they
bite.  :-)  )

LET'S GET PIPELINES IN THE Z/OS BASE!!!

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 11:01 AM, Dyck, Lionel B. (TRA) 
wrote:

> Ask your friendly IBM rep, or search the IBM site, and you won't find it.
> It may be there but it isn't obvious and unless it is integrated it won't
> be exploited by ISVs (or IBM).
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> It's already integrated.  It's just not in the z/OS base.  And you have to
> pay extra.
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) <
> lionel.d...@va.gov>
> wrote:
>
> > PIPES - it would be very nice if IBM were to just integrate PIPES into
> > TSO/REXX and then we can move on and make z/OS an even better platform
> for
> > the future.
> >
> > 
> --
> > Lionel B. Dyck (Contractor)  <
> > Mainframe Systems Programmer – RavenTek Solution Partners
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Hobart Spitz
> > Sent: Friday, May 11, 2018 9:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
> >
> > "pipe listpds" dsn "| stem members."
> >
> > OREXXMan
> > JCL is the buggy whip of 21st century computing.
> > We want Pipelines in the z/OS base.
> >
> > On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo 
> > wrote:
> >
> > > outrap with LISTD works well
> > > soemthing like this works well
> > >
> > >
> > >
> > > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > > If X=16 Then Do
> > > If SYSREASON = 9 Then Do
> > > Say '** Data set has been migrated .. Abort'
> > > Exit
> > > End
> > > If SYSREASON = 5 Then Do
> > > Say '** Data set not cataloged .. Abort'
> > > Exit
> > > End
> > > Else Do
> > > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > > Exit
> > > End
> > > End
> > >
> > >
> > > or even LM services ?
> > > a clist example
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > > ISPEXEC CONTROL ERRORS RETURN
> > > CONTROL END(ENDO)
> > > ISPEXEC LMINIT DATASET('') +
> > > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > > SET  =
> > > GETMBR: +
> > > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > > SET  = 
> > > IF  = 0 THEN DO
> > > SET =()
> > > SET =(1:,)
> > > SET =
> > > ISPEXEC VPUT (MEMPGM)...
> > > and so on
> > >
> > >
> > >
> > > Carmen Vitullo
> > >
> > > - Original Message -
> > >
> > > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Sent: Friday, May 11, 2018 7:56:24 AM
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > > OUTTRAP with LISTD dsname M ?
> > >
> > > I'm pretty sure others will have better suggestions.
> > >
> > > Mike Wawiorko
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Barkow, Eileen
> > > Sent: 11 May 2018 13:42
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > >
> > > ...
> > > Is there any way to get the member names in a PDSE with REXX?
> > > I need to extract the member names in a PDSE and plug them into a job
> > > stream.
> > >
> > > ...
> > >
> > > This e-mail and any attachments are confidential and intended solely
> for
> > > the addressee and may also be privileged or exempt from disclosure
> under
> > > applicable law. If you are not the addressee, or have received this
> > e-mail
> > > in error, please notify the sender immediately, delete it from your
> > system
> > > and do not copy, disclose or otherwise act upon any part of this e-mail
> > or
> > > its attachments.
> > > Internet communications are not guaranteed to be secure or virus-free.
> > The
> > > Barclays Group does not accept responsibility for any loss arising from
> > > unauthorised access to, or interference with, any Internet
> communications
> > > by any third party, or from the transmission of any viruses. Replies to
> > > this 

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Dyck, Lionel B. (TRA)]

Ask your friendly IBM rep, or search the IBM site, and you won't find it. It 
may be there but it isn't obvious and unless it is integrated it won't be 
exploited by ISVs (or IBM).

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: Friday, May 11, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

It's already integrated.  It's just not in the z/OS base.  And you have to
pay extra.

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) 
wrote:

> PIPES - it would be very nice if IBM were to just integrate PIPES into
> TSO/REXX and then we can move on and make z/OS an even better platform for
> the future.
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> "pipe listpds" dsn "| stem members."
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo 
> wrote:
>
> > outrap with LISTD works well
> > soemthing like this works well
> >
> >
> >
> > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > If X=16 Then Do
> > If SYSREASON = 9 Then Do
> > Say '** Data set has been migrated .. Abort'
> > Exit
> > End
> > If SYSREASON = 5 Then Do
> > Say '** Data set not cataloged .. Abort'
> > Exit
> > End
> > Else Do
> > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > Exit
> > End
> > End
> >
> >
> > or even LM services ?
> > a clist example
> >
> >
> >
> >
> >
> >
> >
> > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > ISPEXEC CONTROL ERRORS RETURN
> > CONTROL END(ENDO)
> > ISPEXEC LMINIT DATASET('') +
> > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > SET  =
> > GETMBR: +
> > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > SET  = 
> > IF  = 0 THEN DO
> > SET =()
> > SET =(1:,)
> > SET =
> > ISPEXEC VPUT (MEMPGM)...
> > and so on
> >
> >
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Friday, May 11, 2018 7:56:24 AM
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> > OUTTRAP with LISTD dsname M ?
> >
> > I'm pretty sure others will have better suggestions.
> >
> > Mike Wawiorko
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Barkow, Eileen
> > Sent: 11 May 2018 13:42
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> >
> > ...
> > Is there any way to get the member names in a PDSE with REXX?
> > I need to extract the member names in a PDSE and plug them into a job
> > stream.
> >
> > ...
> >
> > This e-mail and any attachments are confidential and intended solely for
> > the addressee and may also be privileged or exempt from disclosure under
> > applicable law. If you are not the addressee, or have received this
> e-mail
> > in error, please notify the sender immediately, delete it from your
> system
> > and do not copy, disclose or otherwise act upon any part of this e-mail
> or
> > its attachments.
> > Internet communications are not guaranteed to be secure or virus-free.
> The
> > Barclays Group does not accept responsibility for any loss arising from
> > unauthorised access to, or interference with, any Internet communications
> > by any third party, or from the transmission of any viruses. Replies to
> > this e-mail may be monitored by the Barclays Group for operational or
> > business reasons.
> > Any opinion or other information in this e-mail or its attachments that
> > does not relate to the business of the Barclays Group is personal to the
> > sender and is not given or endorsed by the Barclays Group.
> > Barclays Services Limited provides support and administrative services
> > across Barclays group. Barclays Services Limited is an appointed
> > representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> > Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc
> are
> > authorised by the Prudential Regulation Authority and regulated by the
> > Financial Conduct Authority and the Prudential Regulation Authority.
> > Clydesdale Financial Services Limited is authorised and regulated by the
> > Financial Conduct Authority.
> >

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

It's already integrated.  It's just not in the z/OS base.  And you have to
pay extra.

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) 
wrote:

> PIPES - it would be very nice if IBM were to just integrate PIPES into
> TSO/REXX and then we can move on and make z/OS an even better platform for
> the future.
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> "pipe listpds" dsn "| stem members."
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo 
> wrote:
>
> > outrap with LISTD works well
> > soemthing like this works well
> >
> >
> >
> > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > If X=16 Then Do
> > If SYSREASON = 9 Then Do
> > Say '** Data set has been migrated .. Abort'
> > Exit
> > End
> > If SYSREASON = 5 Then Do
> > Say '** Data set not cataloged .. Abort'
> > Exit
> > End
> > Else Do
> > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > Exit
> > End
> > End
> >
> >
> > or even LM services ?
> > a clist example
> >
> >
> >
> >
> >
> >
> >
> > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > ISPEXEC CONTROL ERRORS RETURN
> > CONTROL END(ENDO)
> > ISPEXEC LMINIT DATASET('') +
> > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > SET  =
> > GETMBR: +
> > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > SET  = 
> > IF  = 0 THEN DO
> > SET =()
> > SET =(1:,)
> > SET =
> > ISPEXEC VPUT (MEMPGM)...
> > and so on
> >
> >
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Friday, May 11, 2018 7:56:24 AM
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> > OUTTRAP with LISTD dsname M ?
> >
> > I'm pretty sure others will have better suggestions.
> >
> > Mike Wawiorko
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Barkow, Eileen
> > Sent: 11 May 2018 13:42
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> >
> > ...
> > Is there any way to get the member names in a PDSE with REXX?
> > I need to extract the member names in a PDSE and plug them into a job
> > stream.
> >
> > ...
> >
> > This e-mail and any attachments are confidential and intended solely for
> > the addressee and may also be privileged or exempt from disclosure under
> > applicable law. If you are not the addressee, or have received this
> e-mail
> > in error, please notify the sender immediately, delete it from your
> system
> > and do not copy, disclose or otherwise act upon any part of this e-mail
> or
> > its attachments.
> > Internet communications are not guaranteed to be secure or virus-free.
> The
> > Barclays Group does not accept responsibility for any loss arising from
> > unauthorised access to, or interference with, any Internet communications
> > by any third party, or from the transmission of any viruses. Replies to
> > this e-mail may be monitored by the Barclays Group for operational or
> > business reasons.
> > Any opinion or other information in this e-mail or its attachments that
> > does not relate to the business of the Barclays Group is personal to the
> > sender and is not given or endorsed by the Barclays Group.
> > Barclays Services Limited provides support and administrative services
> > across Barclays group. Barclays Services Limited is an appointed
> > representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> > Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc
> are
> > authorised by the Prudential Regulation Authority and regulated by the
> > Financial Conduct Authority and the Prudential Regulation Authority.
> > Clydesdale Financial Services Limited is authorised and regulated by the
> > Financial Conduct Authority.
> >
> > --
> > 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
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access 

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Dyck, Lionel B. (TRA)]

PIPES - it would be very nice if IBM were to just integrate PIPES into TSO/REXX 
and then we can move on and make z/OS an even better platform for the future.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: Friday, May 11, 2018 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

"pipe listpds" dsn "| stem members."

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo  wrote:

> outrap with LISTD works well
> soemthing like this works well
>
>
>
> X = Listdsi(DSN 'DIRECTORY NORECALL')
> If X=16 Then Do
> If SYSREASON = 9 Then Do
> Say '** Data set has been migrated .. Abort'
> Exit
> End
> If SYSREASON = 5 Then Do
> Say '** Data set not cataloged .. Abort'
> Exit
> End
> Else Do
> Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> Exit
> End
> End
>
>
> or even LM services ?
> a clist example
>
>
>
>
>
>
>
> CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> ISPEXEC CONTROL ERRORS RETURN
> CONTROL END(ENDO)
> ISPEXEC LMINIT DATASET('') +
> DATAID(PDS) ENQ(SHR) ORG(ORG)
> ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> SET  =
> GETMBR: +
> ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> SET  = 
> IF  = 0 THEN DO
> SET =()
> SET =(1:,)
> SET =
> ISPEXEC VPUT (MEMPGM)...
> and so on
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, May 11, 2018 7:56:24 AM
> Subject: Re: [TSO-REXX] Sdsf rexx
>
> OUTTRAP with LISTD dsname M ?
>
> I'm pretty sure others will have better suggestions.
>
> Mike Wawiorko
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barkow, Eileen
> Sent: 11 May 2018 13:42
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [TSO-REXX] Sdsf rexx
>
>
> ...
> Is there any way to get the member names in a PDSE with REXX?
> I need to extract the member names in a PDSE and plug them into a job
> stream.
>
> ...
>
> This e-mail and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this e-mail
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this e-mail or
> its attachments.
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays Group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any Internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this e-mail may be monitored by the Barclays Group for operational or
> business reasons.
> Any opinion or other information in this e-mail or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
> Barclays Services Limited provides support and administrative services
> across Barclays group. Barclays Services Limited is an appointed
> representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are
> authorised by the Prudential Regulation Authority and regulated by the
> Financial Conduct Authority and the Prudential Regulation Authority.
> Clydesdale Financial Services Limited is authorised and regulated by the
> Financial Conduct Authority.
>
> --
> 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
>

--
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: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 23:28:16 +1000, Greg Price  
wrote:

>Yes, you CAN write programs which would work using the same logic in
>AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking
>NOBODY HAS. (Specific counterexamples do not invalidate the point - we
>are talking about the bulk of application software.)

You don't see any value in writing AM-anything
code into the future? Eventually everything will
be AM64-clean and you will have a pure AM64
environment. Pure AM-anything ideally, which
means not using negative indexes in 64-bit
programs and expecting 64-bit wrap/mask.

>Further: Nobody wants to go back and change all their programs so that
>they can work in all these AMODEs.

1. When updating programs for unrelated reasons,
they could be made AM-anything at the same time.

2. Anyone using a high-level language just needs
the compiler to be AM-anything. Next time they
recompile they will pick up the change.

BFN. Paul.

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

Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

"pipe listpds" dsn "| stem members."

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo  wrote:

> outrap with LISTD works well
> soemthing like this works well
>
>
>
> X = Listdsi(DSN 'DIRECTORY NORECALL')
> If X=16 Then Do
> If SYSREASON = 9 Then Do
> Say '** Data set has been migrated .. Abort'
> Exit
> End
> If SYSREASON = 5 Then Do
> Say '** Data set not cataloged .. Abort'
> Exit
> End
> Else Do
> Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> Exit
> End
> End
>
>
> or even LM services ?
> a clist example
>
>
>
>
>
>
>
> CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> ISPEXEC CONTROL ERRORS RETURN
> CONTROL END(ENDO)
> ISPEXEC LMINIT DATASET('') +
> DATAID(PDS) ENQ(SHR) ORG(ORG)
> ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> SET  =
> GETMBR: +
> ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> SET  = 
> IF  = 0 THEN DO
> SET =()
> SET =(1:,)
> SET =
> ISPEXEC VPUT (MEMPGM)...
> and so on
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, May 11, 2018 7:56:24 AM
> Subject: Re: [TSO-REXX] Sdsf rexx
>
> OUTTRAP with LISTD dsname M ?
>
> I'm pretty sure others will have better suggestions.
>
> Mike Wawiorko
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barkow, Eileen
> Sent: 11 May 2018 13:42
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [TSO-REXX] Sdsf rexx
>
>
> ...
> Is there any way to get the member names in a PDSE with REXX?
> I need to extract the member names in a PDSE and plug them into a job
> stream.
>
> ...
>
> This e-mail and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this e-mail
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this e-mail or
> its attachments.
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays Group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any Internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this e-mail may be monitored by the Barclays Group for operational or
> business reasons.
> Any opinion or other information in this e-mail or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
> Barclays Services Limited provides support and administrative services
> across Barclays group. Barclays Services Limited is an appointed
> representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are
> authorised by the Prudential Regulation Authority and regulated by the
> Financial Conduct Authority and the Prudential Regulation Authority.
> Clydesdale Financial Services Limited is authorised and regulated by the
> Financial Conduct Authority.
>
> --
> 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
>

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Steve Thompson]

I've got an observation you and your boss probably won't like.

Windows is based on CP/M (that is what Microsoft started with). 
Guess what CP/M was based on.


Now, here we are 30+ years from M/S and Windows (~ 1983 for first 
release), and they have a lower RAS than does Linux which started 
after them (~1991).


So, perhaps your boss should consider going to Linux Desktops and 
get away from the problems of Windows?


As more and more people go to Linux Desktops, Adobe (and others) 
would have to change their position and go back to supporting 
their products for Linux distros.


And then the *nix file structure being case sensitive would stop 
being a problem, because one would get use to it from working 
with it on a daily basis.


My biggest problem with *nix (POSIX) on z/OS is the goofy way we 
have to define the files for it.


Perhaps the MVS side of z/OS needs to learn to get along with FBA 
and we can stop emulating ECKD with FBA, that then emulate FBA to 
allow POSIX (Unix System Services and related file systems) to 
work on/with z/OS (what overhead).


[FBA boxes seem to be cheaper than the ones that emulate ECKD 
devices -- well at least from where I sit.]


Just my 2 cents.

Regards,
Steve Thompson

On 05/11/2018 09:03 AM, John McKown wrote:

OK, I bet I got your attention on that {grin}.

But, seriously, I am wondering what the "person in the trenches" thinks
about the increasing use of UNIX files and commands becoming more prevalent
on z/OS. I am basically asking because my manager absolutely despises UNIX
files. And hates the current maintenance processes from IBM and CA which
force him to use it. One of his reasons is the case sensitivity of the UNIX
file names. Of course, like most people in the world, his mind has been
corrupted by the case insensitivity of Windows. As well as the very
prevalent use of space characters in Windows file and directory names. This
case sensitivity of names may be another reason why new people, likewise
corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
might find it minimally interesting. And maybe even quite interesting, if
IBM would adopt and maintain a port of the GNU infrastructure software.

What I think, and I am likely stupid on this, is that the Apple HFS+
approach might work. Just like, at present, when you create a zFS
filesystem, the default for filenames on an HFS+ filesystem are, like
Windows, case _in_sensitive. However, when an HFS+ filesystem is
initialized, it can be set as "case sensitive". This is done on a
filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
that it can be made case _in_sensitive (reverse default of HFS+). This
might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
directory (usually /u) under automount and set the parameters so that when
automount creates & initializes a ${HOME} directory, it is
case-insensitive. And, of course, they should be a way to "flip the switch"
back an forth between case sensitivity and case insensitivity. Of course,
the "make insensitive" conversion will need to check & abort if there two
names in the same directory which are equivalent when case is ignored. I
would think this would be simple; check for possible problems and if none,
just flip the switch in some sort of "header" data area.  Regardless of
case sensitivity or insensitivity, it should be case preserving, like
Windows.

I know the response from both IBM and CA is/will be basically "suck it up,
maggot!" (to quote a not-so-favorite D.I.)

Oh, well, it is Friday. And, for me, this is almost a reasonable thought.



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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Hobart Spitz]

I think the real downside is cost of going to a new "platform", even tho
it's still within z/OS.  That means training,
development/conversionj/implementation, testing, deployment, new operations
procedures and training, maintenance, etc.

Add in the general problem of rewriting any software in its entirety.:

   - You can miss important/heavily-used features.
   - You can waste resources on new features that are not really needed or
   cost-effective.
   - You can introduce new bugs.
   - If you change the UI, the users will hate you, your guts, and every
   member of your family, because they will have to spend time learning
   something entirely new when they already knew the old system well.

Don't do it!!!  (Unless you really. really, really have to.)

Second to that are the deficient string and file models:

   - There are separate techniques for processing text, on one hand, and
   binary data on the other.  (z/OS, z/VM have no such requirement.)
   - Using the wrong technique can break data structures badly, as can
   inadvertent/erroneous embedding of binary data in text strings/files.
   (z/OS, z/VM have not such problem.)
   - One of *nix's most powerful features, piping, is crippled because most
   filters are text oriented and cannot process binary data.  Dispatching is
   mostly at the discretion of the operating system.  (Dispatching generally
   deterministic, ands streams can be split and rejoined, because record
   movement is generally defined.)
   - When processing text strings or files, having to scan for the string
   terminator or CR/LF, results in performance-killing working-set/cache
   flooding.  (Pipelines processes records not characters, and unneeded
   pages/cache-lines never have to be staged in.)

The *nix string and file models were great for slow PDP-11s and the like,
but make no sense on modern hardware.

Fixing the 44 character limit?  Do-able:  New control blocks, VTOC records,
catalog entries, JCL parameters, etc.  Much less painful than going to USS.

Just my buck three eighty.  (Pat R., are you out there?)

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 10:06 AM, Charles Mills  wrote:

> Oh for gosh sakes! Every operating system is different. There is no
> eleventh commandment "filenames shall be 44 uppercase characters" that UNIX
> violated. Tell him a foolish consistency is the hobgoblin of little minds.
> Or that the inability to learn new things is a sign of old age.
>
> Or point out that z/OS is case-dependent. Don't think so? Try referencing
> 'sys1.maclib'.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Friday, May 11, 2018 6:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the
> Devil?
>
> OK, I bet I got your attention on that {grin}.
>
> But, seriously, I am wondering what the "person in the trenches" thinks
> about the increasing use of UNIX files and commands becoming more prevalent
> on z/OS. I am basically asking because my manager absolutely despises UNIX
> files. And hates the current maintenance processes from IBM and CA which
> force him to use it. One of his reasons is the case sensitivity of the UNIX
> file names. Of course, like most people in the world, his mind has been
> corrupted by the case insensitivity of Windows. As well as the very
> prevalent use of space characters in Windows file and directory names. This
> case sensitivity of names may be another reason why new people, likewise
> corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
> might find it minimally interesting. And maybe even quite interesting, if
> IBM would adopt and maintain a port of the GNU infrastructure software.
>
> What I think, and I am likely stupid on this, is that the Apple HFS+
> approach might work. Just like, at present, when you create a zFS
> filesystem, the default for filenames on an HFS+ filesystem are, like
> Windows, case _in_sensitive. However, when an HFS+ filesystem is
> initialized, it can be set as "case sensitive". This is done on a
> filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
> that it can be made case _in_sensitive (reverse default of HFS+). This
> might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
> directory (usually /u) under automount and set the parameters so that when
> automount creates & initializes a ${HOME} directory, it is
> case-insensitive. And, of course, they should be a way to "flip the switch"
> back an forth between case sensitivity and case insensitivity. Of course,
> the "make insensitive" conversion will need to check & abort if there two
> names in the same directory which are equivalent when case is ignored. I
> would think this would be simple; check for possible problems and if none,
> just flip the switch 

Re: GETMAIN LOC=32

[Paul Edwards]

Hi Wayne. Let's forget about AM32. There's no
convenient way to add that. All the bits in BSM
are taken already. I would like to be able to run
a pure AM64 z/OS environment though.

You mentioned that AM32 would need to switch
to AM31 because of the variable length parameters.
That is not the case if the AM31 subroutine is
updated to remove the high bit with N x'7FFF'
instead of ignoring the bit or trying to remove it
with LA.

That's fine. That's part of the conversion effort to
produce a pure AM64 site that runs both 32-bit
and 64-bit programs. Better than Windows which
can also do the same thing, but has to stuff
around internally because x64 can't run 32-bit
programs in 64-bit mode, but z/Arch CAN!!!
Maybe this can be a selling point of z/Arch. Pure
64 is possible.

BFN. Paul.




On Fri, 11 May 2018 14:10:59 +, Wayne Driscoll 
 wrote:

>Paul,
>Unlike Hercules, z/Architecture is part of a business, and, as such, a 
>business value needs to be made in order to get support for changes, in 
>particular radical changes like AM32. "it would be nice" and "but it's so 
>cool" aren't business rationalizations for the amount of potentially broken 
>customer code that would result from the change you propose. In order to not 
>have to recompile all applications, or maintain strict bounds between 32 bit 
>apps and 64 bit apps like most other 64 bit architectures, I will gladly 
>sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address 
>space. If your mythical AM32 was invented, applications would still have to 
>switch back to AM31 before calling other AM31 code that expects a variable 
>length paramter list. I still fail to see any business value to IBM's 
>customers in what you are proposing.
>
>Wayne Driscoll
>Rocket Software
>Note - All opinions are strictly my own.
>
>
>
>-Original Messa-e-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Paul Edwards
>Sent: Friday, May 11, 2018 6:23 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Fri, 11 May 2018 03:32:46 -0500, Paul Edwards  wrote:
>
>>ahat I did was provide an option such that any request to activate AM31
>>with BSM instead activates AM32.
>
>BTW, it would be good if z/Arch had a similar option. ie you can configure the 
>hardware so that any attempt to activate AM24 can be overridden to instead 
>activate AM31/32/64.
>Similarly an override for any attempt to activate AM31, and a downgrade option 
>for
>AM64 to activate AM24/31/32.
>
>That way you can set all the overrides to
>AM64 and ensure that everything running
>on your system is AM64-compliant, and
>the system never leaves AM64. A z/OS
>shop would become a pure AM64
>environment.
>
>Unlike Windowa and x64 hardware, 32-bit software can be run natively under 
>AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to 
>x64 and this would be a great selling point I think - a pure 64-bit 
>environment, even when running 32-bit software.
>
>BFN. Paul.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
>Main Office Toll Free Number: +1 855.577.4323
>Contact Customer Support: 
>https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
>Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
>http://www.rocketsoftware.com/manage-your-email-preferences
>Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
>
>
>This communication and any attachments may contain confidential information of 
>Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
>prohibited. If you are not the intended recipient, please notify Rocket 
>Software immediately and destroy all copies of this communication. Thank you.
>
>--
>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: Sample program for JES dataset read?

[Steve Smith]

I'll trust that your look was as good as mine would be.  Maybe it's
considered too elementary to sample.

Oddly, I wrote such code eons ago, like on MVS/XA.  It used some SSI
requests for information, then basically proceeded as that link describes.

sas


On Thu, May 10, 2018 at 8:30 PM, Charles Mills  wrote:

> Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
> looked) - that shows an example of how to allocate and read a JES spool
> dataset?
>
> How to do this, in other words: https://ibm.co/2IbrcGV
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: GETMAIN LOC=32

[Wayne Driscoll]

Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a business 
value needs to be made in order to get support for changes, in particular 
radical changes like AM32. "it would be nice" and "but it's so cool" aren't 
business rationalizations for the amount of potentially broken customer code 
that would result from the change you propose. In order to not have to 
recompile all applications, or maintain strict bounds between 32 bit apps and 
64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB 
out of the massive virtual space offorded by a 64 bit address space. If your 
mythical AM32 was invented, applications would still have to switch back to 
AM31 before calling other AM31 code that expects a variable length paramter 
list. I still fail to see any business value to IBM's customers in what you are 
proposing.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Friday, May 11, 2018 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards  wrote:

>What I did was provide an option such that any request to activate AM31
>with BSM instead activates AM32.

BTW, it would be good if z/Arch had a similar option. ie you can configure the 
hardware so that any attempt to activate AM24 can be overridden to instead 
activate AM31/32/64.
Similarly an override for any attempt to activate AM31, and a downgrade option 
for
AM64 to activate AM24/31/32.

That way you can set all the overrides to
AM64 and ensure that everything running
on your system is AM64-compliant, and
the system never leaves AM64. A z/OS
shop would become a pure AM64
environment.

Unlike Windows and x64 hardware, 32-bit software can be run natively under 
AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to 
x64 and this would be a great selling point I think - a pure 64-bit 
environment, even when running 32-bit software.

BFN. Paul.

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Charles Mills]

Oh for gosh sakes! Every operating system is different. There is no eleventh 
commandment "filenames shall be 44 uppercase characters" that UNIX violated. 
Tell him a foolish consistency is the hobgoblin of little minds. Or that the 
inability to learn new things is a sign of old age.

Or point out that z/OS is case-dependent. Don't think so? Try referencing 
'sys1.maclib'.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, May 11, 2018 6:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

OK, I bet I got your attention on that {grin}.

But, seriously, I am wondering what the "person in the trenches" thinks
about the increasing use of UNIX files and commands becoming more prevalent
on z/OS. I am basically asking because my manager absolutely despises UNIX
files. And hates the current maintenance processes from IBM and CA which
force him to use it. One of his reasons is the case sensitivity of the UNIX
file names. Of course, like most people in the world, his mind has been
corrupted by the case insensitivity of Windows. As well as the very
prevalent use of space characters in Windows file and directory names. This
case sensitivity of names may be another reason why new people, likewise
corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
might find it minimally interesting. And maybe even quite interesting, if
IBM would adopt and maintain a port of the GNU infrastructure software.

What I think, and I am likely stupid on this, is that the Apple HFS+
approach might work. Just like, at present, when you create a zFS
filesystem, the default for filenames on an HFS+ filesystem are, like
Windows, case _in_sensitive. However, when an HFS+ filesystem is
initialized, it can be set as "case sensitive". This is done on a
filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
that it can be made case _in_sensitive (reverse default of HFS+). This
might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
directory (usually /u) under automount and set the parameters so that when
automount creates & initializes a ${HOME} directory, it is
case-insensitive. And, of course, they should be a way to "flip the switch"
back an forth between case sensitivity and case insensitivity. Of course,
the "make insensitive" conversion will need to check & abort if there two
names in the same directory which are equivalent when case is ignored. I
would think this would be simple; check for possible problems and if none,
just flip the switch in some sort of "header" data area.  Regardless of
case sensitivity or insensitivity, it should be case preserving, like

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

On Fri, May 11, 2018 at 8:44 AM, Tony Thigpen  wrote:

> I don't believe that John said anything about the command line parameters.
> He was talking about the file system only. As for the command line, the
> only thing 'affected' would be the name of the command (including any
> path). It could still be entered in lower-case, but he file system would
> find it without regard to the case. So, it could be specified either as
> upper-case or lower-case and still work.


Correct. Most "historic" UNIX commands are both short and lower case.
Making them faster and easier to type on a KSR33 or other "teletype"
terminal.

Another thing, IMO, is that z/OS UNIX "suffers" for a lact of X-client
applications. So "point'n'click" is difficult to implement. But I don't
really believe that IBM is positioning z/OS UNIX as a "end user experience"
product. Just as an "back office infrastructure" product for things like
WAS, CICS Web Services, and so on, to use.



>
>
> Tony Thigpen
>
>
-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Tony Thigpen]

I don't believe that John said anything about the command line 
parameters. He was talking about the file system only. As for the 
command line, the only thing 'affected' would be the name of the command 
(including any path). It could still be entered in lower-case, but he 
file system would find it without regard to the case. So, it could be 
specified either as upper-case or lower-case and still work.


Tony Thigpen

Mike Wawiorko wrote on 05/11/2018 09:29 AM:

Just get used to z/OS Unix (Posix?) being case sensitive.

Many command modifiers have entirely different meanings in either case: command 
-x v. command -X

Mike Wawiorko

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.
Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.
Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.
Barclays Services Limited provides support and administrative services across 
Barclays group. Barclays Services Limited is an appointed representative of 
Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services 
Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the 
Prudential Regulation Authority and regulated by the Financial Conduct 
Authority and the Prudential Regulation Authority. Clydesdale Financial 
Services Limited is authorised and regulated by the Financial Conduct Authority.

--
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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

On Fri, May 11, 2018 at 8:29 AM, Mike Wawiorko <
014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:

> Just get used to z/OS Unix (Posix?) being case sensitive.
>

​I completely agree with you. But many people with a Windows background are
going to be "upset". I don't know how difficult it would be make case
insensitivity selectable ​by filesystem. I think it would be of some use.
But it is "cost vs. benefit" again. And I am not competent to determine
that.



>
> Many command modifiers have entirely different meanings in either case:
> command -x v. command -X
>

​Another thing that Windows corrupted people dislike. But they are a vast
majority, so it make make "marketing" wisdom to bow to them.​



>
> Mike Wawiorko
>
>
-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Mike Wawiorko]

Just get used to z/OS Unix (Posix?) being case sensitive.

Many command modifiers have entirely different meanings in either case: command 
-x v. command -X

Mike Wawiorko   

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.
Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.
Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.
Barclays Services Limited provides support and administrative services across 
Barclays group. Barclays Services Limited is an appointed representative of 
Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services 
Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the 
Prudential Regulation Authority and regulated by the Financial Conduct 
Authority and the Prudential Regulation Authority. Clydesdale Financial 
Services Limited is authorised and regulated by the Financial Conduct Authority.

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

Re: GETMAIN LOC=32

[Greg Price]

On 2018-05-11 9:41 PM, Tom Marchant wrote:

On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:


SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

That illustration in that Redbook is incorrect.



I disagree!!

I think that illustration is correct - and I think it shows the address 
space structure introduced by MVS/XA and which persists till now.


Ok, before z the PSA was only 4K, and not 8K, but apart from that the 
diagram could be for MVS/XA, MVS/ESA or z/OS (BTB).


BTW, I could not see anything relevant on page 6 (maybe I didn't look 
closely enough) but the diagram on page 104 is very plain to see!


The "problem" under discussion is not extended common - it is ELSQA. 
That was why I was rabbiting on about private app storage starting low 
and going higher, and private system storage starting at the "top" and 
growing downwards.


To move ELSQA gets back to the issue of why XA went with AM31 and not 
AM32 in the first place.


Answer: to minimize problems while co-existing with pre-XA software.

And so we come to the central dichotomy of this whole thread.

Yes, you CAN write programs which would work using the same logic in 
AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking 
NOBODY HAS. (Specific counterexamples do not invalidate the point - we 
are talking about the bulk of application software.)


Further: Nobody wants to go back and change all their programs so that 
they can work in all these AMODEs.  But then you may say that no-one is 
asking them to.


To the final kybosh, then:

Nobody who is paying is prepared to risk any reduction in system and/or 
application availability just so that features they will never need or 
use can be added to the system and then debugged by APAR/PTF iterations 
in the service stream. This is on top of the old: the folks who could do 
it won't do it because there is no financial upside on offer.



You got a "if only things had been different" software itch you want to 
scratch?  Sure, explore it, look it over, discuss it, write your own 
software pertaining to it. But don't expect anyone to abandon what they 
are paid to do because you (or I) think they should be more intrigued 
with your (or my) "great computer idea".



Disclaimer:  Much of the above is my opinion and may not be "fact".

But anyway, I do not think there is anything incorrect in the diagram in 
the redbook mentioned above.


Cheers,
Greg P.

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Fri, 11 May 2018 06:42:25 -0500, Tom Marchant wrote:

>On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:
>
>>next to E-Nuc is ESQA, ELPA, ECSA, then E-private.
>
>That illustration in that Redbook is incorrect.

I was mistaken. However, ELSQA has always been at the top.

-- 
Tom Marchant

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

CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[John McKown]

OK, I bet I got your attention on that {grin}.

But, seriously, I am wondering what the "person in the trenches" thinks
about the increasing use of UNIX files and commands becoming more prevalent
on z/OS. I am basically asking because my manager absolutely despises UNIX
files. And hates the current maintenance processes from IBM and CA which
force him to use it. One of his reasons is the case sensitivity of the UNIX
file names. Of course, like most people in the world, his mind has been
corrupted by the case insensitivity of Windows. As well as the very
prevalent use of space characters in Windows file and directory names. This
case sensitivity of names may be another reason why new people, likewise
corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
might find it minimally interesting. And maybe even quite interesting, if
IBM would adopt and maintain a port of the GNU infrastructure software.

What I think, and I am likely stupid on this, is that the Apple HFS+
approach might work. Just like, at present, when you create a zFS
filesystem, the default for filenames on an HFS+ filesystem are, like
Windows, case _in_sensitive. However, when an HFS+ filesystem is
initialized, it can be set as "case sensitive". This is done on a
filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
that it can be made case _in_sensitive (reverse default of HFS+). This
might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
directory (usually /u) under automount and set the parameters so that when
automount creates & initializes a ${HOME} directory, it is
case-insensitive. And, of course, they should be a way to "flip the switch"
back an forth between case sensitivity and case insensitivity. Of course,
the "make insensitive" conversion will need to check & abort if there two
names in the same directory which are equivalent when case is ignored. I
would think this would be simple; check for possible problems and if none,
just flip the switch in some sort of "header" data area.  Regardless of
case sensitivity or insensitivity, it should be case preserving, like
Windows.

I know the response from both IBM and CA is/will be basically "suck it up,
maggot!" (to quote a not-so-favorite D.I.)

Oh, well, it is Friday. And, for me, this is almost a reasonable thought.

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: [TSO-REXX] Sdsf rexx

[Carmen Vitullo]

outrap with LISTD works well 
soemthing like this works well 



X = Listdsi(DSN 'DIRECTORY NORECALL') 
If X=16 Then Do 
If SYSREASON = 9 Then Do 
Say '** Data set has been migrated .. Abort' 
Exit 
End 
If SYSREASON = 5 Then Do 
Say '** Data set not cataloged .. Abort' 
Exit 
End 
Else Do 
Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON 
Exit 
End 
End 


or even LM services ? 
a clist example 







CONTROL PROMPT NOFLUSH NOMSG END(ENDO) 
ISPEXEC CONTROL ERRORS RETURN 
CONTROL END(ENDO) 
ISPEXEC LMINIT DATASET('') + 
DATAID(PDS) ENQ(SHR) ORG(ORG) 
ISPEXEC LMOPEN DATAID() OPTION(INPUT) 
SET  = 
GETMBR: + 
ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM) 
SET  =  
IF  = 0 THEN DO 
SET =() 
SET =(1:,) 
SET = 
ISPEXEC VPUT (MEMPGM)... 
and so on 



Carmen Vitullo 

- Original Message -

From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, May 11, 2018 7:56:24 AM 
Subject: Re: [TSO-REXX] Sdsf rexx 

OUTTRAP with LISTD dsname M ? 

I'm pretty sure others will have better suggestions. 

Mike Wawiorko 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen 
Sent: 11 May 2018 13:42 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [TSO-REXX] Sdsf rexx 


... 
Is there any way to get the member names in a PDSE with REXX? 
I need to extract the member names in a PDSE and plug them into a job stream. 

... 

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its 
attachments. 
Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons. 
Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group. 
Barclays Services Limited provides support and administrative services across 
Barclays group. Barclays Services Limited is an appointed representative of 
Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services 
Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the 
Prudential Regulation Authority and regulated by the Financial Conduct 
Authority and the Prudential Regulation Authority. Clydesdale Financial 
Services Limited is authorised and regulated by the Financial Conduct 
Authority. 

-- 
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: [TSO-REXX] Sdsf rexx

[Mike Wawiorko]

OUTTRAP with LISTD dsname M  ?

I'm pretty sure others will have better suggestions.

Mike Wawiorko 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: 11 May 2018 13:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Sdsf rexx


...
Is there any way to get the member names in a  PDSE with REXX?
I need to extract the member  names in a PDSE and plug them into a  job stream.

...

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.
Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.
Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.
Barclays Services Limited provides support and administrative services across 
Barclays group. Barclays Services Limited is an appointed representative of 
Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services 
Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the 
Prudential Regulation Authority and regulated by the Financial Conduct 
Authority and the Prudential Regulation Authority. Clydesdale Financial 
Services Limited is authorised and regulated by the Financial Conduct Authority.

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Fri, 11 May 2018 00:59:14 -0700, Glen wrote:

>the 360/67 has 32 bit virtual addressing, along with BAS and
>BASR to use it.

Yes, but not BSM or BASSM.

IIRC changing AMODE required a privileged instruction.

The Functional Characteristics manual is on Bitsavers.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Allan Staller]

Stop poking the bear! 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, May 10, 2018 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Somewhere along the way, you seem to have missed the point.  Which is, the 
proposal is REJECTED, with prejudice.  It has no more chance than a baby june 
bug in a 100-watt zapper (unless your org. provides >5% of IBM's revenue, and 
Ginny R. always answers your calls).

Y'all feel free to continue down your primrose path, perhaps noting that no one 
is listening to you anymore.  You've come up with a solution to a problem no 
one has.  The best way to shorten this tiresome thread would be to stop 
extending it.  Nevertheless, I'm confident P. Edwards will have to have the 
last word. Which is fine and dandy; but the sooner the better.

sas

On Thu, May 10, 2018 at 5:27 PM, somitcw < 
01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:

> ​...
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that would
> double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: [TSO-REXX] Sdsf rexx

[Barkow, Eileen]

Thanks for the critique Hobart.
 Actually the intention of the SINGALS was to terminate the loops and other 
constructs.
This clist was a conversion from an SDSF BATCH process  to extract and archive 
the files and it was my first experience with SDSF/REXX so
I was more interested in the conversion process than in writing elegant REXX 
code, but I will take your comments into consideration the
Next time I write some REXX code, which I may have to do shortly.

So maybe you or some other REXX guru can help me with this:
Is there any way to get the member names in a  PDSE with REXX?
I need to extract the member  names in a PDSE and plug them into a  job stream.
I know how to get the file names in a HFS directory but have not seen anything 
to extract the PDSE member names.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: Thursday, May 10, 2018 9:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Sdsf rexx

For those who may not be aware, SIGNAL is *not* a GOTO.

I counted 18 SIGNALs, and only 1 CALL.  Many of the SIGNALs here seem to
have been better done with DO...END.

In the words of TRL, SIGNAL terminates "all active pending DO loops, DO
groups, IF constructs, SELECT construct, and INTERPRET instructions" such
that "they cannot be reactivated".

With apologies to Eileen and/or the original coder:  Not being aware of
that fact has apparently let the coder down into a "black hole".  I hope my
post can encourage anyone who thinks this is the way to write REXX, to do
better, and that anyone who copies sees this code not use it as an model
for anything.

This is not an issue of style, pedantics, or personal preference.  Using
SIGNAL this way is even more of a barrier to maintainable, readable code
than a GOTO.  For more information, see the appropriate resources.

It should not even be necessary to say it, but I vote for SIGNAL-less
coding (except for SIGNAL ON/OFF, and where actually necessary.)

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Tue, May 8, 2018 at 4:18 PM, Barkow, Eileen 
wrote:

> This is a SDSF/REXX clist that extracts sysout datasets with names S*
> on the ST queue and archives them to datatsets.
> It can be adapted to extract datasets with other criteria.
>
> /* REXX */
> TRACE e
> /*ISFTRACE="ON" */
> /*ISFTRMASK="ALL" */
> PROFILE NOPREFIX
> rc=isfcalls('ON')
> PARSE ARG p1 p2 p3
> IF p1 ="" THEN DO
> ISFPREFIX = 'CICS*'
> END
> ELSE
> DO
> ISFPREFIX = p1
> END
> IF p2 ="" THEN DO
> HLQ   = 'XCICSR.'
> END
> ELSE
> DO
> HLQ   = p2||'.'
> END
> IF p3 ="" THEN DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ELSE
> DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ISFOWNER  = '*'
> ISFFILTER = 'QUEUE PRINT'
> CICSJOBN = ISFPREFIX
> ASTPO = POS('*',CICSJOBN)
> if ASTPO ^= 0 then
> do
> ASTPO = ASTPO - 1
> CICSJOBN = SUBSTR(CICSJOBN,1,ASTPO)
> end
> /* Access the ST panel. A TOKEN variable is */
> /* created for each row which is subsequently */
> /* needed to perform actions */
> Address SDSF "ISFEXEC ST"
> lrc=rc
> call msgrtn
> /* Find a job starting with CICSjobn and list data sets */
> /* rexx */
> numrows=isfrows
> if isfrows<=0 then exit
> six = 1
> setix:
> if six > numrows then signal endit
> do ix=six to numrows /* Loop for all rows returned */
> if pos(CICSJOBN,JNAME.ix) = 1 then /* If this is desired row */
> do
> /* Issue the ? action character for the job */
> /* identified by the token variable. Note */
> /* the token must be enclosed in single quotes */
> /* Use the prefix option to ensure unique */
> /* variables are created, beginning with JDS_ */
> Address SDSF "ISFACT ST TOKEN('"TOKEN.ix"') PARM(NP ?)",
> "("prefix JDS_
> if JDS_DDNAME.0 = 0 then exit
> lrc=rc
> if lrc<>0 then
> exit 20
> startjx = 2
> jf = 0
> IF JDS_DDNAME.0 =1 then signal SETJL1
> /***if 2 jesmsglgs use 2nd  */
> do jf = 2 to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jf,1,4) = 'JESM' then signal GETJLINF
> end
> SETJL1:
> startjx = 1
> GETJLINF:
> do jx=startjx to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jx,1,4) = 'JESM' then signal GOTJESM
> end
> signal nextjob
> lrc=rc
> call msgrtn
> if lrc<>0 then do
> exit 20
> GOTJESM:
> sjx= jx  /*save position of current ddname entry */
> Address SDSF "ISFACT ST TOKEN('"JDS_TOKEN.jx"') PARM(NP SA)"
> lc = rc
> k = isfddname.0
> /***READ 3RD   RECORD TO GET STARTED TASK NUMBER  */
>  "EXECIO 1  DISKR " isfddname.k 3 " (STEM STCREC. "
>  lrc = rc
>  If lrc ^= 0 THEN SIGNAL NOSTC
>  PARSE VAR STCREC.1  S1 STRNUM S3
>  STRNUM = STRIP(STRNUM)
>  STCNUM = SUBSTR(STRNUM,1,8)
> /***READ 4TH   RECORD TO GET JOBNAME  */
>  "EXECIO 1  DISKR " isfddname.k 4 " (STEM STCREC. "
>  PARSE VAR STCREC.1  X1 X2 X3 JN XX
>  JN = STRIP(JN)
>  "EXECIO 0  DISKR " isfddname.k  " (finis"
>  sjx = sjx+1
>  signal setjx
> setjx:
> IF sjx >  

Re: GETMAIN LOC=32

[Tom Marchant]

On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:

>SG24-7605-00
>z/OS Version 1 Release 10 Implementation
>April 2009
>Pages 6 and 104
>Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

That illustration in that Redbook is incorrect.

>When did they move?

They didn't.

>Are we requesting a feature that is already there?
>IBM could do that real quick.
>
>Paul's wanting SVC 120 to get memory up to 4GB-1 and
>have IARV64 and IARST64 stick with 33 to 64bit addresses
>would actually need a couple of code changes and a little
>documentation.

You don't have a clue what would be required to compatibly dumb down 
AMODE 64 the way you want it. It is something that provides no benefit 
for z/OS users, despite all your protestations to the contrary.

I agree with Steve, Charles, Jim and others. This is a waste of time.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards  wrote:

>What I did was provide an option such that any
>request to activate AM31 with BSM instead
>activates AM32.

BTW, it would be good if z/Arch had a similar
option. ie you can configure the hardware so
that any attempt to activate AM24 can be
overridden to instead activate AM31/32/64.
Similarly an override for any attempt to
activate AM31, and a downgrade option for
AM64 to activate AM24/31/32.

That way you can set all the overrides to
AM64 and ensure that everything running
on your system is AM64-compliant, and
the system never leaves AM64. A z/OS
shop would become a pure AM64
environment.

Unlike Windows and x64 hardware, 32-bit software
can be run natively under AM64. It doesn't need a
special mode. Basically z/Arch hardware is
superior to x64 and this would be a great
selling point I think - a pure 64-bit environment,
even when running 32-bit software.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Fri, 11 May 2018 00:59:14 -0700, Glen  wrote:

>As far as I know, IBM did produce a mainframe with 32 bit virtual
>addressing.
>
>There might not be many around, and I don't think Hercules has this
>mode,

Hercules/380 has been updated to support AM32.
What I did was provide an option such that any
request to activate AM31 with BSM instead
activates AM32. That means that I have to choose
between AM31 and AM32 - I can't have both. And
all my AM31 applications also need to be AM32
capable.

>but the 360/67 has 32 bit virtual addressing, along with BAS and
>BASR to use it.

How did that work? Did a high bit in BASR
cause AM32 to be activated?

Thanks. Paul.

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

Re: GETMAIN LOC=32

[Glen]

As far as I know, IBM did produce a mainframe with 32 bit virtual 
addressing.


There might not be many around, and I don't think Hercules has this 
mode, but the 360/67 has 32 bit virtual addressing, along with BAS and 
BASR to use it.


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

AW: Re: GETMAIN LOC=32

[Peter Hunkeler]

Paul, are you continuing to bother us under a new pseudonym now?

--
Peter Hunkeler


 Von: somitcw <01b1f179dc6e-dmarc-requ...@listserv.ua.edu> An:  
 IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: GETMAIN LOC=32 Datum: 11.05.18, 07:29


SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

When did they move?
Are we requesting a feature that is already there?
IBM could do that real quick.

Paul's wanting SVC 120 to get memory up to 4GB-1 and
have IARV64 and IARST64 stick with 33 to 64bit addresses
would actually need a couple of code changes and a little
documentation.



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