Re: GETMAIN LOC=32

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

Re: [TSO-REXX] Sdsf rexx

> On May 10, 2018, at 10:30 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > ——SNIP--- > > Fear of indention is collateral damage of RECFM=FB,80. When Rexx first came > to TSO it came with a GIM that recommended

Re: [TSO-REXX] Sdsf rexx

On Thu, 10 May 2018 21:09:48 -0400, Hobart Spitz wrote: >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

Re: GETMAIN LOC=32

Agreed. And I'll wager any readers of the Herc lists will not have been surprised at the way this thread progressed... Lee B. On 2018年5月11日 9:01:24 GMT+09:00, "Jackson, Rob" wrote: >Hear hear. I wholeheartedly agree. This started off bewildering; then >it

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

Re: Anybody running this?

I don't think the agenda for St. Louis has been published yet, but Eysha Powers did a z14 Crypto Update in Sacramento. Roan Dawkins did a similar session at IBM Tech U in Orlando last week. Greg Greg Boyd www.mainframecrypto.com On Thu, 10 May 2018 17:05:39 -0500, Edward Gould

Re: GETMAIN LOC=32

Thank you, but I don't believe that that is what Paul trying to do? Paul requested GETMAIN LOC=2GBto4GB-1.if.unavailable.16MBto4GB-1.if.unavailable.0Bto16MB-1 Moving extended common to put it near the common E-Nuc was not originally thought of. Is there anyway the "already available" could

Sample program for JES dataset read?

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

Re: PDSE V2 Corruption - A Warning - Correction (kinda)

> Also, there is an interesting (at least for me) RFE that proposes either to > change the Edit of an "old" member generation to View, or to allow the Edit > but save it like a new generation. Here => > http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=101120 FWIW, the default

Re: GETMAIN LOC=32

Hear hear. I wholeheartedly agree. This started off bewildering; then it became entertaining; now it's just irritating. I'm adding a filter to dump "GETMAIN LOC=32" in deleted. This has turned from a flight of fantasy into a waste of resources. First Tennessee Bank Mainframe Technical

Re: GETMAIN LOC=32

It would be a waste of time to submit such an RFE. GETMAIN will not be changed to manage addresses above 2GB. Extended common will not be moved. The interface to allocate the storage in the 2GB to 4GB-1 address range is already available - IARV64 GETSTOR with USE2GTO32G=YES Jim

Re: Anybody running this?

> On May 10, 2018, at 1:05 PM, Greg Boyd wrote: > > I know of several customers running this newest level. The other new > function is support for STATs. That's an option you can enable to generate > SMF records with counters on use of engines, algorithms and

Re: Tapeless delivery

https://www.theregister.co.uk/2018/05/10/ibm_bans_all_removable_storage_for_all_staff_everywhere/ Not sure what hoops you will have to jump through to send any data on any media soon. On Sat, Apr 28, 2018 at 3:25 AM, Edward Gould wrote: >> On Apr 27, 2018, at 1:01 PM, J

Re: GETMAIN LOC=32

Amen. Flagellum equus mortuus. The suggested wording for the RFE is "never mind." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, May 10, 2018 2:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re:

Re: GETMAIN LOC=32

On Thu, 10 May 2018 16:27:50 -0500, somitcw wrote: >The RFE would double the addressable memory with an address >storable in four bytes for data for an AMODE 64 program. >That is an incredible enhancement allowed for AMODE 64 programs. I'm glad someone else can see that!

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

Re: GETMAIN LOC=32

Tom Marchant posted: >On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote: >This is a matter of defining "best programming >>practices" and noting that you can't rely on the >>BALR crap byte > est for you perhaps. Using only a limited subset of the instruction set.

Re: GETMAIN LOC=32

On Thu, 10 May 2018 14:35:08 -0500, Tom Marchant wrote: >>This is a matter of defining "best programming >>practices" and noting that you can't rely on the >>BALR crap byte > >Best for you perhaps. Using only a limited subset of the instruction set. >And you don't

z/OSMF Data Directory Location

On May 1st (when I wasn't looking), the PTF for z/OSMF APAR PI92211 closed. This PTF moves the default location for the z/OSMF data directory from under /var (a system-specific directory) to under /global (a sysplex-wide directory) with updated samples and documentation. This move puts the

Re: PDSE V2 Corruption - A Warning - Correction (kinda)

Hey fellas, Apparently the APAR has been closed and PTFs are: z/OS 2.1 UA96169; z/OS 2.2 UA96170; z/OS 2.3 UA96168 Also, there is an interesting (at least for me) RFE that proposes either to change the Edit of an "old" member generation to View, or to allow the Edit but save it like a new

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote: >This is a matter of defining "best programming >practices" and noting that you can't rely on the >BALR crap byte Best for you perhaps. Using only a limited subset of the instruction set. And you don't seem to understand the value of the

Re: Anybody running this?

I know of several customers running this newest level. The other new function is support for STATs. That's an option you can enable to generate SMF records with counters on use of engines, algorithms and services. Could be a significant step forward in monitoring your crypto workload. Greg

Re: Knowledge Centre - (was Re: Rant)

Hi Sue, thanks for the follow up. I sent you a direct email so I could include screen prints of what I'm getting. Thanks, Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Susan Shumway Sent: Thursday, May 10, 2018 8:51 AM To:

Re: GETMAIN LOC=32

On Thu, 10 May 2018 11:01:12 -0500, Paul Edwards wrote: >> If it's bimodal than it's not running under >> OS/VS2 3.8 (MVS). > >Confusion in terms again. > >By "bimodal" I mean "capable of being run >as *either* AM24 or AM31". ie IEFBR14 is bimodal. Even trimodal in fact.

Re: GETMAIN LOC=32

On Thu, 10 May 2018 15:29:15 +, Seymour J Metz wrote: > If it's bimodal than it's not running under > OS/VS2 3.8 (MVS). Confusion in terms again. By "bimodal" I mean "capable of being run as *either* AM24 or AM31". So yes, a bimodal 32-bit module, like the ones I create,

Re: GETMAIN LOC=32

If it's bimodal than it's not running under OS/VS2 3.8 (MVS). If it's bimodal and it is running into memory constraints, trimodal is only a bandaid; it needs a rewrite as AMODE64. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM

Re: GETMAIN LOC=32

The question isn't whether AMOD24 behavior can be dispensed with; it's tracking down all of the existing code that has to be changed. How many people are changing memory constrained AMOD24 code to AMODE31 these days, rather than rewriting it as AMODE64? How many errors will get introduced in

Re: arm police

While you can cancel IRLM or DB2, this should only be done as a last resort if DB2 is not responding to -STOP DB2 or -STOP DB2 MODE(FORCE). In ancient times when there were real tape drives, DB2 would hang waiting for a tape mount to archive logs when the logs had all filled or if a QMF user hit

Re: arm police

What version of z/OS? What version of DB2? Did you google IBM DB2 ARM POLICY I found the following hit that may be helpful https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/inst/src/tpc/db2z_createautorestartpolicy.html Also, you might want to post on the DB2 List as this

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:24:18 -0500, Joe Monk wrote: >"Allowing 32-bit registers to address 32-bit virtual >addresses is not a limitation/constraint. It is the >ultimate you can get from a 32-bit register." > >It is if it breaks all existing code in the process. Not ALL

Re: GETMAIN LOC=32

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz wrote: >How do run, in AMODE64, an AMODE24 program that > relies on bits 0-7 after a BAL or BALR? The same way you do when you are faced with converting your code to bimodal AMODE31 - you don't write code like that, and it is

Re: GETMAIN LOC=32

"Allowing 32-bit registers to address 32-bit virtual addresses is not a limitation/constraint. It is the ultimate you can get from a 32-bit register." It is if it breaks all existing code in the process. You can't take away what you call the "crap byte" in BALR and expect existing code to

Re: GETMAIN LOC=32

Admittedly IEFBR14 will work fine in AMOD64 if the high 32 bits of R14 and R15 are zero. However, if you have to deal with legacy 24-bit code, then you have to deal with the incompatibility between AMODE24 and AMODE64. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:09:32 -0500, Joe Monk wrote: >For instance, if you look at his PDOS, the command processor is named >command.com. He wants the mainframe to behave like a big PC-DOS box, and so >he is trying to impose the same limitations/constraints, etc. Allowing

Re: GETMAIN LOC=32

How do run, in AMODE64, an AMODE24 program that relies on bits 0-7 after a BAL or BALR? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Edwards

Re: GETMAIN LOC=32

There are no address registers or data registers, only general registers, which prior to z were 32 bits. XA and ESA mode only used 31 bits for addressing, with the high bit designating addressing mode (except when it didn't). The behavior of some instructions is different in 24 bit mode. --

Re: GETMAIN LOC=32

What Paul can't separate in his mind is that a machine can have larger registers than it has memory addresses (i.e. 32-bit registers but 24-bit AMODE). Thats where most of this is coming from ... his attempts to make the mainframe be a PC. For instance, if you look at his PDOS, the command

Re: GETMAIN LOC=32

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz wrote: > Actually, the 32 bit registers go back *before* > S/370. The issue is compatibility of AMODE24 code. Which was solved initially by making code bimodal (24/31), but it would be good if people made that code trimodal

Re: Knowledge Centre - (was Re: Rant)

Hi Bart, I followed your example on Firefox and wasn't able to recreate a reset nav. First, I opened the nav and clicked the pushpin icon at the top right corner to pin it open. I then clicked through the nav to the "MVS system commands reference" topic and then clicked the "MODIFY command"

Re: GETMAIN LOC=32

Actually, the 32 bit registers go back *before* S/370. The issue is compatibility of AMODE24 code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Edwards

Re: Anybody running this?

Yes On Wed, 9 May 2018 18:48:38 -0500, Edward Gould wrote: >ICSF Delivers With the New FMID HCR77C1 Release >Usability improvements, such as an ISPF-based browser for CKDS key material, >and integrated support for a PCI HSM configured CCA coprocessor, are among the

Re: GETMAIN LOC=32

On Thu, 10 May 2018 09:57:22 +0200, Bernd Oppolzer wrote: >just for the record: > >to support 32 bit virtual addresses, it is not really needed >that the underlying hardware supports 32 bit real addresses. >It would be possible to support 32 bit virtual on a 31 bit

Re: Anybody running this?

Yes. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe

Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:45:46 -0500, Joe Monk wrote: >Once again, you dont comprehend. > >IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64. And non-XA IBM 370 CANNOT run AMODE 31. So what? What's your point. Yes, I know some hardware supports AM24 only, some

Re: GETMAIN LOC=32

Am 10.05.2018 um 04:31 schrieb Tony Thigpen: Paul said: > You're quibbling over semantics. A program that > uses 32-bit data registers and 32-bit address > registers and 32-bit code pointers and 32-bit > data pointers is a 32-bit load module. There is just so much wrong with that statement.

arm police

hi all In our shop, DB2 is registered as an element of the automatic restart manage The detailed information is shown below.ELEMENT(elementname) RESTART_METHOD(SYSTERM,STC,'cmdprfx STA DB2,LIGHT(YES)')If we cancel db2 ,db2 will be restarted by arm . We don't hope db2 will be restarted by

Re: GETMAIN LOC=32

Paul Edwards wrote: >The 32-bit load modules I produce run on MVS 3.8j, MVS/XA, OS/390 and z/OS. Ok. On what hardware are you working? Say for example, 3090, z890, z990, zEC12, z13, etc. ? I am sure you know IBM will NOT accept any request(s) for unsupported systems and hardware like MVS