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

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

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

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

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

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

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

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

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

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

Re: GETMAIN LOC=32

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

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

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

Re: Sample program for JES dataset read?

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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,

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

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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

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

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)

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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

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

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

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

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

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

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

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

Re: [TSO-REXX] Sdsf rexx

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 |

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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:

Re: Sample program for JES dataset read?

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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

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

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

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

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

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

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.

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

Re: [TSO-REXX] Sdsf rexx

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

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

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

PIPES (was Sdsf rexx)

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

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

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

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

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

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

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

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

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 –

Re: GETMAIN LOC=32

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

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

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

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

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

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

Re: GETMAIN LOC=32

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

Re: Sample program for JES dataset read?

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

Re: GETMAIN LOC=32

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

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

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

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

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 >

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

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

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

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

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

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

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

Re: [TSO-REXX] Sdsf rexx

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

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:

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: [TSO-REXX] Sdsf rexx

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

Re: GETMAIN LOC=32

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

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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.

AW: Re: GETMAIN LOC=32

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