Re: Netview Login issue

venkat kulkarni wrote: >We using Netview 6.2. Now problem has been resolved by one of the major node . >Now i am able to login to netview for use. Are you saurabh khandelwal collaborating to resolve this Netview logon problem? It would be great to see if the OP has his/her problem resolved or

Re: GETMAIN LOC=32

Jim Mulder wrote: > GETMAIN is not going to ever manage 32-bit storage. I would word you > requirement this way: > " I would like to have a USE2GTO4G=NO|YES parameter on IARV64 GETSTOR, > similar to the already exisiting USE2GTO32G=NO|YES and USE2GTO64G=NO|YES. > And I would like to have a

Re: DFSORT help

Hi, here a sample: //ST002EXEC PGM=SORT //SYSOUTDD SYSOUT=* //SORTIN DD DISP=SHR,DSN=MYDCOLLECT //SORTOUT DD SYSOUT=* //SYSIN DD * OPTION VLSCMP INCLUDE COND=(9,2,BI,EQ,C'D ',AND, ONLY TYPE 'D' 74,1,BI,NE,B'..1.',AND, NO TEMPORARY

Knowledge Centre - (was Re: Rant)

Susan Shumway wrote: >You're hired, Elardus! ;-) Thanks for your nice compliment, I am humbled by your comments. Ok, but I am way too expensive - starting at $1 million per second, can you afford that? ;-D Ok, seriously. >My own broken record statement is that we're constantly trying to

Re: GETMAIN LOC=32

Paul Edwards wrote: >However, *as well as* GETMAIN having the capability I have no problem with >other facilities such as IARV64 being able to do the same thing. I see no reason to hold back GETMAIN. And note that if a program using the IARV64 macro with the new parameter is run on an older

Re: GETMAIN LOC=32

On Mon, 7 May 2018 02:58:38 -0500, Elardus Engelbrecht wrote: >> GETMAIN is not going to ever manage 32-bit >> storage. I would word you requirement this way: > Why specific GETMAIN? What about STORAGE macro? For an existing 32-bit program, being able to

Re: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder wrote: >> GETMAIN is not going to ever manage 32-bit storage. >> I would word you requirement this way: > > " I would like to have a USE2GTO4G=NO|YES > parameter on IARV64 GETSTOR, Hi Jim. Thanks for the interesting suggestion,

Re: Job submit using REXX

Lizette Koehler wrote: >This process can be done by using a trap for a message on your system. >MPF Exit might work >CBTTAPE.ORG might have a process you can tailor >Any Scheduling software will have a file trigger function >This is more complicated without scheduling software. You will need to

Re: GETMAIN LOC=32

Paul, I thing you are just 'digging your heels in' at this point and not listening to what people are trying to tell you. I suggest you re-read some of the responses with a more open mind. Tony Thigpen Paul Edwards wrote on 05/07/2018 09:51 AM: On Mon, 7 May 2018 08:42:00 -0500, Joel C.

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant wrote: >>Updating 32-bit programs to conform to >>AM64 requirements is far less onerous >>than the massive changes required to >>create a 64-bit application. > >No, it isn't. Why do you think it is? All references to "L"

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:05:19 -0500, Tom Marchant wrote: >>If GETMAIN is modified as I requested, >>the 16 MiB to 4 GiB region will be a continuous >>region and a GETMAIN of 3 GiB will work so long >>as there hasn't been fragmentation. ie a 32-bit >>program can allocate

Re: GETMAIN LOC=32

On Mon, 7 May 2018 04:15:50 -0500, Paul Edwards wrote: >For an existing 32-bit program, being able to >change LOC=31 or LOC=ANY to LOC=32 is >the simplest change, and on an old system >it will still work, just obtaining LOC=31 memory >instead of LOC=32 memory, better than nothing. You want to

Re: GETMAIN LOC=32

On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote: >As far as I can tell, the BAR exists for the same >reasons that 16 MiB LINE exists - historical >curiosity. Right. And compatibility >No reason to be stuck with that forever. >Most other 32-bit programming environments >allow access to

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:09:40 -0500, Paul Edwards wrote: >What terminology do you suggest using for a >program that only uses the 32-bit registers >as found in S/370, but may be running in any >AMODE including AM64? "Short-sighted." -- Tom Marchant

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote: >Oh - I'm also assuming that IBM will update >the operating system so that READ etc can >be executed in AM64. ROFL! You didn't ask for that. I think that you are assuming that is is trivial. Are you also assuming that they will accept an

Re: GETMAIN LOC=32

On 05/07/2018 07:39 AM, Tom Marchant wrote: > On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote: > >> As far as I can tell, the BAR exists for the same >> reasons that 16 MiB LINE exists - historical >> curiosity. > Right. And compatibility > >> No reason to be stuck with that forever. >>

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing wrote: >From the early days of S/360 the high-order bit of a full-word address >pointer has a documented function in standard subroutine linkage of >indicating the last parameter address for subroutines that accept a >variable

Re: Job submit using REXX

If this is only for one dataset and the message is in SYSLOG, then the MPF list would work. If there are multiple datasets that need to be available before proceeding, then it is getting to be a bit trickier. Several Scheduling software have Dataset Triggers. And they sometimes will monitor

IZUGUTSE ?

I have been reading the new z/OSMF Redbook and found in section 4.5 info about IZUGUTSE (gutsy) that appears to generate XML for use with establishing z/OSMF security regardless of the ESM. BUT I've not found any information about it in the z/OS 2.3 internet library, knowledge center, etc. I

Re: GETMAIN LOC=32

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote: > > >Oh - I'm also assuming that IBM will update > >the operating system so that READ etc can > >be executed in AM64. > > ROFL! You didn't

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:51:05 -0500, Paul Edwards wrote: >Updating 32-bit programs to conform to >AM64 requirements is far less onerous >than the massive changes required to >create a 64-bit application. No, it isn't. Why do you think it is? -- Tom Marchant

Re: GETMAIN LOC=32

On Mon, 7 May 2018 05:32:16 -0500, Paul Edwards wrote: >If GETMAIN is modified as I requested, >the 16 MiB to 4 GiB region will be a continuous >region and a GETMAIN of 3 GiB will work so long >as there hasn't been fragmentation. ie a 32-bit >program can allocate a single 3 GiB chunk. No, it

Re: GETMAIN LOC=32

The term "32-bit program" has been repeated in this thread. It appears that the OP means by this that the program can be AMODE 31 or AMODE 64 but never directly touches bits 0-31 of a GR. It appears that the OP is interested in expanding the program to accommodate twice as much storage as it

Re: Job submit using REXX

If it is only in the STC Job log, or other DD statement, then no. The request would then require something like ISFEXEC (SDSF REXX) and it would not be real time. It would then have to be run at a frequency that makes sense. Anything not presented to the SYSLOG/OPERLOG would not be seen by the

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:49:31 +, Allan Staller wrote: >AM64 is very different than what you are have been asking for in this thread. > >z/OS currently supports 3 addressing modes; >AM24, AM31 and AM64. What you are asking for is a major re-architecting of >z/OS to

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:29:23 -0500, Tom Marchant wrote: >>Oh - I'm also assuming that IBM will update >>the operating system so that READ etc can >>be executed in AM64. > >ROFL! You didn't ask for that. I didn't ask for it yet because the first step is to just have

Re: RMM tape init question

On Mon, May 7, 2018 at 8:48 AM, Tony Thigpen wrote: > We have recently converted to RMM. I need to init a bunch of used tapes > that already have a volid. I have hit several problems and it just seems > that the only way to do what I need is to process the tapes twice. > >

Re: GETMAIN LOC=32

Hi, on behalf of a customer we discussed the idea of something like transparent 64bit to 31bit mirroring. Such that IARV64 has an option like MAP31BIT=YES which gives you an address back that allows existing 31bit programs to address this area without copying. Every access off that returned

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant wrote: >>For an existing 32-bit program, being able to >>change LOC=31 or LOC=ANY to LOC=32 is >>the simplest change, and on an old system >>it will still work, just obtaining LOC=31 memory >>instead of LOC=32 memory,

Re: GETMAIN LOC=32

AM64 is very different than what you are have been asking for in this thread. z/OS currently supports 3 addressing modes; AM24, AM31 and AM64. What you are asking for is a major re-architecting of z/OS to create AM32. As (IIRC) Peter Relson pointed out that JAVA is able to use this storage. As

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:15:45 -0400, Peter Relson wrote: >The term "32-bit program" has been repeated in this thread. It appears >that the OP means by this that the program can be AMODE 31 or AMODE 64 but >never directly touches bits 0-31 of a GR. Thanks for providing that

RMM tape init question

We have recently converted to RMM. I need to init a bunch of used tapes that already have a volid. I have hit several problems and it just seems that the only way to do what I need is to process the tapes twice. Using EDGINERS, it appears that you can only change a volid if the existing volid

Re: GETMAIN LOC=32

On Mon, 7 May 2018 09:00:37 -0500, Paul Edwards wrote: >I just want z/OS to match MVS/380, >and there is nothing technically preventing >that from happening. Nothing, except all the z/OS changes that you haven't considered, and all the application changes they might imply

Re: GETMAIN LOC=32

In article <3154560307111841.wa.mutazilahgmail@listserv.ua.edu> you wrote: > On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant > wrote: > >>Updating 32-bit programs to conform to > >>AM64 requirements is far less onerous > >>than the massive changes required to >

Re: [EXTERNAL] Re: IZUGUTSE ?

Found those which reference the redbook where I learned about gutsy. :-) Thanks - now to figure out how to use it as there is zero doc that I can find. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer -

Re: GETMAIN LOC=32

​It seems you want IBM to do a lot of work to save you a little. Not very likely, I think. Java manages to address 32GB with 32-bit pointers. 4GB would be simpler.​ -- sas -- For IBM-MAIN subscribe / signoff / archive

Re: RMM tape init question

On 5/7/2018 10:43 AM, Tony Thigpen wrote: Thanks. I was looking at the SYSIN parms for EDGINERS and never noticed that there were additional options as a parm on the EXEC card. I will try this later today. These tapes have had their external labels removed to facilitate putting new robot

Re: RMM tape init question

Thanks. I was looking at the SYSIN parms for EDGINERS and never noticed that there were additional options as a parm on the EXEC card. I will try this later today. These tapes have had their external labels removed to facilitate putting new robot labels that are within our normal volid

Re: IZUGUTSE ?

But did you use Google? When I did I came up with a few more hits including IBM z/OS Management Facility V2R3 [Book] - Safari Books Online https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/ 4.4 Authorizing a user to use z/OSMF . 4.4.1 Using RACF commands to authorize a

Re: GETMAIN LOC=32

The current implementation of IARV64 GETSTOR with USE2GTO32G=YES is to do a first-fit search from low address to high address of the 2GBTO32GB area. So if there is available space below 4GiB, that is what you will get. Since that implementation detail is not documented, it is not guaranteed

Re: [EXTERNAL] Re: IZUGUTSE ?

here is the xml: IZU.AIZUFS(IZUGUTSA) and it looks like this: http://www.ibm.com/systems/zos/saf; xmlns:racf="htt . . . ..APPL ..APPL ..APPL . . . . ..EJBROLE ..EJBROLE ..EJBROLE . . . . ..FACILITY ..FACILITY ..FACILITY . . . . . . . . . . . . . . . . . . . . . .

Re: DFSMSdss Question

>From the DFSMSdss Storage Administration TYPRUN=NORUN For copy, dump, restore, compress, and release operations, only input data set selection is done without actually processing data sets. Printed output for the run indicates the data sets selected. For a defragmentation operation, the

Re: Job submit using REXX

On Mon, 7 May 2018 20:46:36 +, Phil Carlyle wrote: >When using QUEUE() for output the last record needs to be NULL in order to >completely flush the buffers. > I see no such statement in: TSO/E REXX Reference Version 2 Release 3 SA32-0972-30 Where do you see it? What do you mean by

DFSMSdss Question

Is there any way to get a listing of datasets on a dss dump tape? This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, "CIT"), and

Re: [EXTERNAL] Re: IZUGUTSE ?

But who, other than IBM, in their right mind would hand code XML? I got the impression, probably wrong, that the gutsy routine provided a more user friendly interface (at least that was my hope). -- Lionel B. Dyck

Re: GETMAIN LOC=32

> Why can't GETMAIN LOC=32 call IARV64 as above > under the covers so that the only change I need to > make to my application code is replace LOC=ANY > with LOC=32? Because there is not a sufficient financial benefit to IBM to spend the money to implement anything like that. > Note that

Re: DFSMSdss Question

run a restore of the tape with no run option ( I forget the spelling). it will list what it would have restored and just end On Mon, May 7, 2018 at 3:21 PM, Porowski, Kenneth wrote: > Is there any way to get a listing of datasets on a dss dump tape? > > > >

Re: Job submit using REXX

When using QUEUE() for output the last record needs to be NULL in order to completely flush the buffers. PHIL CARLYLE Information Security | IAM RACF directory services M: 480-235-2837 | phil.carl...@aexp.com TEKSystems “The Universe is made up of Protons,

CICS and DB2

Has anyone managed to configure a connection from CICSTS running on z/OS to a DB2 UDB running on Windows? Specifically without having to have DB2 on z/OS. This email message and any accompanying materials may contain proprietary, privileged and confidential

Re: [EXTERNAL] Re: IZUGUTSE ?

Lots of people use XML. It is handy for translating X to Y in a platform independent manner. That being said, I would only use XML if forced to by business/applications constraints. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of

Re: CICS and DB2

If you have not done so you might try posting on either the CICS or DB2 lists To join, use these URLs DB2 http://www.idug.org/ CICShttp://www.listserv.uga.edu/archives/cics-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List On

Re: Job submit using REXX

Venkat - what I think you should consider is hiring a consultant to help you with this. I do not want to discourage from posting questions. That is how we all learn. But there are limits as to what an Internet list can assist with. Using a consultant you will get Knowledge Transfer

Re: Job submit using REXX

On Mon, 7 May 2018 14:57:34 -0400, Tony Thigpen wrote: >Phil, > >Your statement confuses me. Please elaborate. >What you are stating does not match my knowledge of REXX, QUEUE, and EXECIO. >Tony Thigpen > >Phil Carlyle wrote on 05/07/2018 02:46 PM: >> You forgot the QUEUE ‘’ to flush out the

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote: >Why can't GETMAIN LOC=32 call IARV64 as above >under the covers so that the only change I need to >make to my application code is replace LOC=ANY >with LOC=32? Because FREEMAIN wouldn't work with an address in that range. You are asking to

Re: GETMAIN LOC=32

I don't agree that supporting GETMAIN between 2GiB and 4GiB would be elegant, although it might have some practical utility. I also suspect that it would cause more problems than it solved. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:34:58 -0500, Paul Edwards wrote: >But you are happy to constrain >32-bit applications to 2 GiB when all you may >need is a LOC=32 parameter and you can go >all the way up to 4 GiB. No, you also have to run AMODE(64), which means that there are many system services that you

Re: GETMAIN LOC=32

I am an insider with respect to the VSM and RSM components of z/OS, and the comments below are pretty accurate. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > - IMO, IBM will not perceive any ROI from your request sufficient to > make them consider it.

Re: GETMAIN LOC=32

On Mon, 7 May 2018 14:19:24 -0500, Tom Marchant wrote: >FREEMAIN wouldn't work with an address in that range. I may have been mistaken about this. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access

Re: Job submit using REXX

Hello Lizette, I do agree and always grateful to this list to help beginners and will take care in future. One of expert mentioned that Direct Connect has feature to submit batch job once it receive that particular file. If that is the case then my whole problem will be resolved. I tried

Re: GETMAIN LOC=32

LOL! Charles Mills wrote: Rouge operating systems make me see red! Charles -- 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

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards wrote: >Yes, I believe we should START this process by >allowing for 32-bit addressing. With a goal of >only having software that runs AM64 - regardless >of whether it is a 32-bit or 64-bit program. I'm certainly not going to put any effort into

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote: >> " I would like to have a USE2GTO4G=NO|YES >>parameter on IARV64 GETSTOR, similar to the already exisiting >>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES. >>And I would like to have a way to tell the system to reserve the

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:33:03 -0500, Tom Marchant wrote: >>Yes, I believe we should START this process by >>allowing for 32-bit addressing. With a goal of >>only having software that runs AM64 - regardless >>of whether it is a 32-bit or 64-bit program. > >I'm certainly

Re: GETMAIN LOC=32

I just realized what is happening. Paul is involved with the rouge development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit. Now that they have a non-conforming operating system, they want the real operating system people to support some of the stuff they did in the rouge

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards If high-level language compilers start following >the 32-bit addressing rules, they will naturally >start supporting 4 GiB with no additional >effort by the programmer. If high level language compilers (and run-time environments) start following

Re: GETMAIN LOC=32

On Mon, 7 May 2018 10:56:48 -0500, Paul Edwards wrote: >That's a good idea, and we could get a compiler >to generate such code, but it prevents the >32-bit application from being moved to cheaper >32-bit hardware in the future, as a possibility. OMFG! Is that what this is all about? Moving to

Re: Job submit using REXX

You forgot the QUEUE ‘’ to flush out the queue. 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

Re: Job submit using REXX

Hello Phil, Thanks for reply. As I am new to REXX, can you please help me in sample rexx program for this task. On Mon, May 7, 2018 at 9:46 PM, Phil Carlyle < 0190521b6517-dmarc-requ...@listserv.ua.edu> wrote: > You forgot the QUEUE ‘’ to flush out the queue. > > PHIL CARLYLE > Information

Re: GETMAIN LOC=32

Rouge operating systems make me see red! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, May 7, 2018 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I just realized what is

Re: Job submit using REXX

Phil, Your statement confuses me. Please elaborate. What you are stating does not match my knowledge of REXX, QUEUE, and EXECIO. Tony Thigpen Phil Carlyle wrote on 05/07/2018 02:46 PM: You forgot the QUEUE ‘’ to flush out the queue. PHIL CARLYLE Information Security | IAM RACF directory

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:29:31 -0500, Paul Edwards wrote: >No, what you are calling a 24-bit application is >actually a 32-bit application that runs on a >reduced addressing mode of 24. You are making up your own terminology, using words similar to those of existing terminology. >I want my

Re: GETMAIN LOC=32

Yes, the high bit convention has to change for interfaces that accept 64 bit addresses. The issue is that in order to change the convention for 32 bit programs, either 1 - an additional AMODE would need to be supported by the hardware, or 2 - EVERY existing program would have to be redesigned

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll wrote: > Yes, the high bit convention has to change for > interfaces that accept 64 bit addresses. The issue > is that in order to change the convention for 32 > bit programs, either 1 - an additional AMODE > would

Re: Netview Login issue

Hello Elardus, Yes, we both together putting effort to solve this issue.. Thank you so much once again. On Mon, May 7, 2018 at 10:30 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > venkat kulkarni wrote: > > >We using Netview 6.2. Now problem has been resolved by one of the

Re: IZUGUTSE ?

Lizette Koehler wrote: >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online >https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/ Thanks, but Safari and that Red-hot spanner on the front page of that RedBook is blocking/burning me to read it... ;-) Try this link

Re: GETMAIN LOC=32

Congratulations; you've invented OS/VS1. I'd also like to see that for DSORG=PO, with ACB-based equivalents to BLDL, FIND and STOW. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll wrote: >>>Changing the documented conventions for using the high-order bit of a >>>32-bit address word >>This convention *already* has to change for anyone considering moving to AM64 >>and using 64-bit pointers.

Re: Job submit using REXX

Check with your Netview automation team, this process is easily handled there if this is a critical process it would be the best place to put anyway. Using the right message traps and establishing the proper variables, it would not matter how many data sets are in the process and the return

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:38:58 -0400, Tony Thigpen wrote: >You keep saying 32-bit applications. There is *NO SUCH THING*. There are >only 24-bit, 31-bit and 64-bit applications. How do you distinguish between applications that only use the S/370 32-bit registers and applications

Re: Job submit using REXX

On Sun, 6 May 2018 14:45:24 +0300, venkat kulkarni wrote: > >We have requirement of setting up process of handling FTP and then submit >Job with FTP dataset. ... > FTP has the ability to submit jobs directly with the command: QUOTE SITE FILETYPE=JES Would this meet your reaquirement? --

Re: Job submit using REXX

Hello Group, Thanks for all response. We have Netview, which can be used for automation. My idea is to create REXX, which extracted data from DCON address space into one dataset. Then i need help to write REXX to extract FTP.DATA.** dataset from this ps dataset and put these dataset name into

Re: GETMAIN LOC=32

> On May 7, 2018, at 8:42 AM, Joel C. Ewing wrote: >> ——SNIP--- > One of the big advantages of IBM mainframes (since S/360) has been > upward compatibility for application code. Unlike other platforms, you > don't have

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras wrote: >> All references to "L" to load an address need >> to be changed to "LG". > >Not necessarily. When we implemented large heap support for SAS/C, we >used a scheme where we could avoid re-writing large parts of the >assembler

Re: GETMAIN LOC=32

Paul, You keep saying 32-bit applications. There is *NO SUCH THING*. There are only 24-bit, 31-bit and 64-bit applications. Tony Thigpen Paul Edwards wrote on 05/07/2018 11:56 AM: On Mon, 7 May 2018 11:02:28 -0400, Don Poitras wrote: All references to "L" to load an

Re: GETMAIN LOC=32

To the original requirement of "support a LOC=32 parameter to GETMAIN, giving 32-bit programs access to a full 4 GiB instead of the current 2 GiB provided by LOC=31." Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES and then GETMAIN if that fails to find storage?

Re: GETMAIN LOC=32

The IARV64 instruction probably will find memory. But it will be a 64-bit address requiring me to manipulate and save 64-bit registers. I wish to write 32-bit programs, and I also want those 32-bit programs to run on OS/390 as AM31 and on MVS 3.8j as AM24. Only on z/OS and MVS/380 would my 32-bit

Re: Job submit using REXX

REXX i used to copy DCON address space message into ps file is ADDRESS TSO DO I=0 TO 4 "ALLOC F(ISFIN) TRACKS SPACE(1) REU" "ALLOC F(ISFOUT) NEW DELETE REU ", "TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)" "ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE" QUEUE "PRE DCON" QUEUE "ST"

Re: GETMAIN LOC=32

[Warning: long post. No world records, but feel free to skip it.] Paul, I think your request is unrealistic. I raise the following points - some of which have been mentioned or alluded to by others - for your consideration: - IMO, IBM will not perceive any ROI from your request sufficient

Re: [EXTERNAL] Re: IZUGUTSE ?

Nothing in samplib :( This must be a very secure tool - security by obscurity. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe

Re: GETMAIN LOC=32

On Tue, 8 May 2018 03:32:03 +1000, Greg Price wrote: >I think z/OS has diverged too far from its MVS/370 predecessor where you >could, perhaps, successfully implement your idea. Ok, well hopefully we are only about 100 lines of code away from MVS/380 supporting

Re: Where do I find a list of world timezones in z/OS USS notation?

On Thu, 26 Apr 2018 16:21:57 -0500, Juan Escamilla wrote: >I had to change the Unix time zone values for several LPARS that run on >different timezones around the world. I used the values from website >https://www.di-mgt.com.au/src/wclocktz.ini > Thanks. I bookmarked it. Somewhat incomplete

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:18:38 -0500, Paul Edwards wrote: >strip >the high bit with an N to x'7FFF' LLGT/LLGTR -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder wrote: > GETMAIN is not going to ever manage 32-bit storage. >I would word you requirement this way: > > " I would like to have a USE2GTO4G=NO|YES >parameter on IARV64 GETSTOR, similar to the already exisiting >USE2GTO32G=NO|YES

Re: Job submit using REXX

Connect:Direct also has the ability to submit jobs via the RUNJOB verb. Since the files appear to be received by Connect:Direct, wouldn't it be possible to change the receiving process to submit the job too. -Original Message- From: IBM Mainframe Discussion List

Re: IZUGUTSE ?

Lionel, have you looked in sys1.samplib(*izu*) ITschak On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Lizette Koehler wrote: > > >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online >

Re: GETMAIN LOC=32

Another reason: Peter says it ain't gonna happen Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: Monday, May 7, 2018 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 [Warning: long post.

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:01:42 -0500, Paul Edwards wrote: >The IARV64 instruction probably will find >memory. But it will be a 64-bit address >requiring me to manipulate and save >64-bit registers. You chose to ignore Jim Mulder's reply. -- Tom Marchant

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:44:38 -0500, Paul Edwards wrote: >How do you distinguish between applications >that only use the S/370 32-bit registers and >applications that use the z/Arch 64-bit >registers, Are you suggesting that a 24-bit application, one that runs AMODE(24), only uses 24-bit

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:18:51 -0500, Tom Marchant wrote: >>The IARV64 instruction probably will find >>memory. But it will be a 64-bit address >>requiring me to manipulate and save >>64-bit registers. > You chose to ignore Jim Mulder's reply. Replied now. >>How do you