Re: Data Center Index for SE Texas?

[Edward Gould]

> On Aug 29, 2017, at 11:28 PM, Edward Finnell 
> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Just curious if anybody's keeping score?
> 
> https://www.yahoo.com/amphtml/finance/news/waffle-houses-hurricane-response-
> team-prepares-disaster-184844452.html
> 
> Another useful index would for the ..edu's


Ed:
A company I used to work for had their DR site in TE, although not sure where.
If the guy I know is still working there he’ll talk.

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

Re: IBM to finally drop JES3

[Edward Gould]

> On Aug 29, 2017, at 11:36 PM, Edward Finnell 
> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> 
> They were on it back in the eighties as Uni JES. Think it's badge 464.  
> Summa cum JES-"get it up once, keep it up forever". Bob Shannon reported the  
> politics and ambitions were too orthogonal and was dropped early nineties.

Edward:

Way back in the 70’s or early 80’s I was ahead of the TSO project (don’t 
remember now if it was Share or Guide). Anyway one members was a really big 
JES3 person. He wanted all sort of things that the rest of the members did not 
want we spent countless hours arguing about JES3 this and that. If I remember 
correctly he was with Standard Oil. The IBMers were getting mad as he was 
monopolizing the conversation and trying to get JES3 code into TSO commands etc 
etc. They threatened to leave and finally I asked the guy to leave as he was 
disrupting the group. He disappeared and never showed up again. We actually did 
a white paper on TSO and IBM just wasn’t interested, I think it was because of 
the JES3 person, but I never could get a word out of them.

Ed


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

AW: EZAFTPKS from Started task

[Peter Hunkeler]

>I have been testing out a started task under TESTAUTH (it does APF
authorized command).



I'm curious. How can you test out "a started task under TESTAUTH" (or TEST)? I 
know only how to test programs in my TSO session using these commands.


--
Peter Hunkeler

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

Re: IBM to finally drop JES3

[Edward Finnell]

They were on it back in the eighties as Uni JES. Think it's badge 464.  
Summa cum JES-"get it up once, keep it up forever". Bob Shannon reported the  
politics and ambitions were too orthogonal and was dropped early nineties.
 
 
In a message dated 8/29/2017 10:54:20 P.M. Central Daylight Time,  
charl...@mcn.org writes:

Write to  Harry dot Williams (a) marist dot  edu



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

Data Center Index for SE Texas?

[Edward Finnell]

Just curious if anybody's keeping score?
 
https://www.yahoo.com/amphtml/finance/news/waffle-houses-hurricane-response-
team-prepares-disaster-184844452.html
 
Another useful index would for the ..edu's

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

Re: IBM to finally drop JES3

[Edward Gould]

> On Aug 29, 2017, at 8:21 PM, Edward Gould  wrote:
> 
> According to Watson blog post,
> Some other statements of direction (SOD) include: stabilization of DFS/SMB 
> because NFS is the strategic file sharing protocol; last release to provide 
> national language translation in languages other than Japanese; last release 
> to support user keys for system storage (CSA, ECSA, ESQA, SCOPE=COMMON data 
> spaces); and the most interesting of all – stabilization of JES3, with all 
> future development being done on JES2. 
> 
> I’ll bet the JES3 group at SHARE will not be happy.
> There maybe some who will offer their version of JES3 to the “public”.
> 
> Ed

No, I let the junior people go to the parties now. My traveling days are over.

Ed

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

Re: The BIGGEST Z Machine - Sandia National Laboratories' Z machine,

[Edward Gould]

> On Aug 29, 2017, at 8:49 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On 2017-08-29, at 17:29, Edward Gould wrote:
> 
>> http://www.dailygalaxy.com/my_weblog/2017/08/the-z-machine-worlds-most-powerful-x-ray-duplicates-a-black-holes-disk-upending-existing-theories.html?utm_source=feedburner_medium=email_campaign=Feed%3A+TheDailyGalaxyNewsFromPlanetEarthBeyond+%28The+Daily+Galaxy+--Great+Discoveries+Channel%3A+Sci%2C+Space%2C+Tech.%29
>>  
>> 
>> 
>> (watch the wrap)
>> 
> I can't parse the first sentence in that article.
> 
> But I think it's a different "Z”.

Gil,

Yes I knew that, but I think IBM has started capitalizing “Z” I thought it 
would be fun to see how other companies are handling it. Not sure if IBM knew 
about this or not, or whether its a TM or not.
Ed
> 
> -- 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: IBM to finally drop JES3

[Charles Mills]

Were you at SHARE? SHARE is "on it." They are working on a statement of 
position to IBM. Have an opinion? Write to Harry dot Williams (a) marist dot edu

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Tuesday, August 29, 2017 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM to finally drop JES3

According to Watson blog post,
Some other statements of direction (SOD) include: stabilization of DFS/SMB 
because NFS is the strategic file sharing protocol; last release to provide 
national language translation in languages other than Japanese; last release to 
support user keys for system storage (CSA, ECSA, ESQA, SCOPE=COMMON data 
spaces); and the most interesting of all – stabilization of JES3, with all 
future development being done on JES2. 

I’ll bet the JES3 group at SHARE will not be happy.
There maybe some who will offer their version of JES3 to the “public”.

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

Re: The BIGGEST Z Machine - Sandia National Laboratories' Z machine,

[Edward Finnell]

Not even a computer just a big Tesla coil.
 
 
In a message dated 8/29/2017 8:49:31 P.M. Central Daylight Time,  
000433f07816-dmarc-requ...@listserv.ua.edu writes:

But I  think it's a different "Z".

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

Re: The BIGGEST Z Machine - Sandia National Laboratories' Z machine,

[Paul Gilmartin]

On 2017-08-29, at 17:29, Edward Gould wrote:

> http://www.dailygalaxy.com/my_weblog/2017/08/the-z-machine-worlds-most-powerful-x-ray-duplicates-a-black-holes-disk-upending-existing-theories.html?utm_source=feedburner_medium=email_campaign=Feed%3A+TheDailyGalaxyNewsFromPlanetEarthBeyond+%28The+Daily+Galaxy+--Great+Discoveries+Channel%3A+Sci%2C+Space%2C+Tech.%29
>  
> 
> 
> (watch the wrap)
>  
I can't parse the first sentence in that article.

But I think it's a different "Z".

-- gil

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

IBM to finally drop JES3

[Edward Gould]

According to Watson blog post,
Some other statements of direction (SOD) include: stabilization of DFS/SMB 
because NFS is the strategic file sharing protocol; last release to provide 
national language translation in languages other than Japanese; last release to 
support user keys for system storage (CSA, ECSA, ESQA, SCOPE=COMMON data 
spaces); and the most interesting of all – stabilization of JES3, with all 
future development being done on JES2. 

I’ll bet the JES3 group at SHARE will not be happy.
There maybe some who will offer their version of JES3 to the “public”.

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

Re: EZAFTPKS from Started task

[John McKown]

This is an S0C1 a end. Debug it from the CEEDUMP or SYSUDUMP.

On Aug 29, 2017 17:13, "Joseph Reichman"  wrote:

> hI
>
>
>
> I have been testing out a started task under TESTAUTH (it does APF
> authorized command). In addition it uses EZAFTPKS to download a file to
> windows, this works fine under TEST
>
>
>
> When I know try to run the code I get the following abend
>
>
>
> BPXP018I THREAD 1FD85002, IN PROCESS 16842778, ENDED
>
> WITHOUT BEING UNDUBBED WITH COMPLETION CODE 840C1000
>
> , AND REASON CODE 0001.
>
>
>
> After doing some research on EZAFTPKS it says that it has to have a OMVS
> segment defined I am far from RACF expert but I am wondering if anyone has
> had similar experiences and might be able to shed some light
>
>
>
> Thanks
>
>
> --
> 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: EZAFTPKS from Started task

[Charles Mills]

That's not an ABEND. It's an informational message. The following is informal 
-- don't take it to the bank:

That message says that a conventional "MVS" program was doing UNIX stuff and 
ended without cleaning up the UNIX environment. In my experience it is usually 
an additional symptom of some other error, not the cause of the problem.

Yes, to do any "UNIX stuff" the userid needs an "OMVS segement." Different 
symptoms if you are missing that:

ICH408I USER(xx ) GROUP(xx   ) NAME(x xx ) CL(PROCESS ) OMVS 
SEGMENT NOT DEFINED

and/or Language Environment ABEND U4093-90 and/or message

CEE5101C During initialization, the callable service BPX1MSS failed. The system 
return code was 000156 , the reason code was 0B0C00FB . The application 
will be terminated.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, August 29, 2017 5:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EZAFTPKS from Started task

FTP is an OMVS command.
You must have a RACF OMVS segment to use any OMVS commands.

On Tue, Aug 29, 2017 at 5:13 PM, Joseph Reichman  wrote:
> hI
>
>
>
> I have been testing out a started task under TESTAUTH (it does APF 
> authorized command). In addition it uses EZAFTPKS to download a file 
> to windows, this works fine under TEST
>
>
>
> When I know try to run the code I get the following abend
>
>
>
> BPXP018I THREAD 1FD85002, IN PROCESS 16842778, ENDED
>
> WITHOUT BEING UNDUBBED WITH COMPLETION CODE 840C1000
>
> , AND REASON CODE 0001.

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

Re: EZAFTPKS from Started task

[Mike Schwab]

FTP is an OMVS command.
You must have a RACF OMVS segment to use any OMVS commands.

On Tue, Aug 29, 2017 at 5:13 PM, Joseph Reichman  wrote:
> hI
>
>
>
> I have been testing out a started task under TESTAUTH (it does APF
> authorized command). In addition it uses EZAFTPKS to download a file to
> windows, this works fine under TEST
>
>
>
> When I know try to run the code I get the following abend
>
>
>
> BPXP018I THREAD 1FD85002, IN PROCESS 16842778, ENDED
>
> WITHOUT BEING UNDUBBED WITH COMPLETION CODE 840C1000
>
> , AND REASON CODE 0001.
>
>
>
> After doing some research on EZAFTPKS it says that it has to have a OMVS
> segment defined I am far from RACF expert but I am wondering if anyone has
> had similar experiences and might be able to shed some light
>
>
>
> Thanks
>
>
> --
> 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

The BIGGEST Z Machine - Sandia National Laboratories' Z machine,

[Edward Gould]

http://www.dailygalaxy.com/my_weblog/2017/08/the-z-machine-worlds-most-powerful-x-ray-duplicates-a-black-holes-disk-upending-existing-theories.html?utm_source=feedburner_medium=email_campaign=Feed%3A+TheDailyGalaxyNewsFromPlanetEarthBeyond+%28The+Daily+Galaxy+--Great+Discoveries+Channel%3A+Sci%2C+Space%2C+Tech.%29
 


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

Re: Looking for mainframe shops Lexington/Cincinnati

[Edward Gould]

> On Aug 29, 2017, at 8:15 AM, Allan Staller  wrote:
> 
> WKRP? 
> 
> 


I was easting Thanksgiving dinner when I saw that episode. I laughed so hard 
the food came flying out of my mouth. I don’t think I have ever laughed that 
hard.

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

Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Thomas David Rivers]

Tom Marchant wrote:


On Tue, 29 Aug 2017 15:59:53 -0400, Thomas David Rivers wrote:

 


The doc seems ambiguous to me; which leads me down this path
of doing funky save-area machinations to ensure that all registers
are saved - not just the "normal" ones.
   



STM  14,12,12(13)
hardly constitutes "doing funky save-area machinations".

Saving your caller's registers is a good practice, if for no other reason than 
to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

 

Oh yes!  I *totally* agree - the problem is a little involved... I'm 
branching to

some code that wants a save area, but I'm not in position to allocate one.
So - I can't save the incoming registers in the OS-provided area just to 
have

the branched-to routine overwrite that... the restore would then not restore
the proper registers.

It's a twisty maze of save-area stuff to be sure...

(It's a "thunk" between two stacks... - these things happen...)

If I didn't have to save/restore R15 and R1, then I could totally get away
with something very close to standard linkage... that's my basic 
question/hope.


- Dave Rivers -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

Agreed.

An easier approach by far would be to have my recovery routine retry to a 
routine that issued a distinct user ABEND in AMODE 31, perhaps first copying 
the SDWA to some storage that could subsequently be displayed.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Tuesday, August 29, 2017 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

On 2017-08-29 17:44, Bernd Oppolzer wrote:
> Would the following approach help?
> 
>  From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask 
> and waits for its completion.
> 
> The subtask does all the 64 bit AMODE switching (and return), and 
> establishes an ESTAE exit (or other technique) to handle errors that 
> occur inside the subtask.
> If errors occurs, you return information about the error to the C/C++ 
> main task (normal return, not percolate), which then can signal the 
> error and activate the LE error handling, as usual, so you can do your 
> garbage collection tasks etc.

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

Re: Message IRX0006I running an edit macro CLIST

[CM Poncelet]

Ah yes, that makes sense. I did not realise that ISPEXEC SELECT
PGM(J00YCKAL) PARM(JLRCL) actually processed the dataset being edited.
So ISREDIT MACRO is required in that case.
 
Cheers, CP
 

On 29/08/2017 17:54, Jesse 1 Robinson wrote:
> I have no stake in defending the JEM CLIST, but AFAIK 'ISREDIT MACRO' is 
> required in order to run it from the command line with just 'jem'. For better 
> or for worse, that's how people use the product. You're in edit on a JCL 
> member. Before submitting, you execute JEM to increase your chances of 
> getting a clean run. It does more than check JCL syntax. It also tries to 
> check that data sets referred to actually exist and that in general the logic 
> flow is at least superficially valid. Invoked as simply as possible. 
>
> PROC is not required for this function. Up to now, PROC never got in the way 
> of successful execution. 
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of CM Poncelet
> Sent: Monday, August 28, 2017 6:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: :Re: Message IRX0006I running an edit macro CLIST
>
> FWIW
>
> The oddity is that there are *no* edit macro statements after "ISREDIT MACRO 
> (PARMSTR)". So why is an edit macro declared in the Clist?
>  
> E.g. "ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.can be issued directly 
> from the Clist proc and does not need an edit macro to do that.
>  
> Sure, edit macros are normally invoked from the command line in edit mode. 
> But they can also be invoked by Clist and REXX procs, and then not from the 
> command line. So if JEM is a Clist that in turn invokes an edit macro, then 
> 'TSO JEM + any parms' would be used to invoke JEM as a Clist (and ISPF option 
> 6 could invoke it simply as 'JEM + any parms'). So, is JEM meant to be 
> invoked as a Clist ("PROC 0 ...") or as an edit macro ("ISREDIT MACRO 
> ()")?
>  
> I give up.
>  
> Cheers, CP
>  
>
> On 28/08/2017 15:52, Jesse 1 Robinson wrote:
>> That is exactly the case. Like most (maybe all) edit macros), JEM is 
>> executed directly on the command line. Running it as TSO command (tso 
>> jem) would fail to establish the proper connection to ISPF. I tried 
>> that and got
>>
>> EDIT MACRO ERROR
>> EDIT MACRO INITIALIZATION FAILURE.  CHECK EDIT MACRO CLIST.
>>
>> I did not see Paul Feller's post except as quoted by CM Poncelet. As CM 
>> notes, there are two parms: DSJNAME and PARMSTR. It seems odd that one is 
>> defined on the PROC statement and the other on the ISREDIT MACRO statement, 
>> but that's the way it's supplied to the customer. 
>>
>> I have no problem learning that an old loophole has been closed. But closed 
>> is closed, and what fails in one place should fail everywhere with the fix 
>> is place. The person who first reported the problem here is a true mainframe 
>> veteran. He uses JEM more than anyone else I know. 
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> 626-543-6132 Office ⇐=== NEW
>> robin...@sce.com
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Lizette Koehler
>> Sent: Sunday, August 27, 2017 8:31 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: (External):Re: Message IRX0006I running an edit macro CLIST
>>
>> Typically the user is EDITing a PDS Member with JCL and enters JEM on 
>> the command line
>>
>> Lizette
>>
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>> On Behalf Of CM Poncelet
>>> Sent: Sunday, August 27, 2017 7:11 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Message IRX0006I running an edit macro CLIST
>>>
>>> There are two parms for this Clist: DSJNAME and PARMSTR. How is JEM invoked?
>>> (E.g. it could be invoked as "TSO JEM HLQ.DSJN1.THEREST MACPARM2".)
>>>
>>> On 27/08/2017 18:25, Feller, Paul wrote:
 One last comment.  We run the same software and have not had an 
 issue in
>>> three different SYSPLEX environments.  I looked to the most recent 
>>> versions of the software we have.  The JEM CLIST is shipped that way from 
>>> the vendor.
>>> Very interesting.
 BROWSESYSI.JOBSCAN.R790.AJJSCLST.HS(JEM) - 01. Line 00 Col 001
>>> 080
  Command ===>  Scroll ===>
>>> CSR
 * Top of Data
>>> *
   PROC 0  DJSNAME(X.X)
   CONTROL END(ENDO) NOMSG NOFLUSH
 /*CONTROL END(ENDO) MSG LIST CONLIST SYMLIST NOFLUSH /*S80725*/
   ISREDIT MACRO (PARMSTR)

   IF 

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Gord Tomlin]

On 2017-08-29 17:44, Bernd Oppolzer wrote:

Would the following approach help?

 From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.

The subtask does all the 64 bit AMODE switching (and return), and 
establishes
an ESTAE exit (or other technique) to handle errors that occur inside 
the subtask.
If errors occurs, you return information about the error to the C/C++ 
main task
(normal return, not percolate), which then can signal the error and 
activate
the LE error handling, as usual, so you can do your garbage collection 
tasks etc.


Kind regards

Bernd


I think an approach like this would only be reasonable of the volume of 
calls to the 64-bit code are very infrequent. If the 64-bit routine(s) 
is/are called a lot, the overhead would be prohibitive.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Webster, Chris]

Using BAKR on entry frees up the provided save area for other uses.

...chris.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: August-29-17 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

On Tue, 29 Aug 2017 15:59:53 -0400, Thomas David Rivers wrote:

>The doc seems ambiguous to me; which leads me down this path of doing 
>funky save-area machinations to ensure that all registers are saved - 
>not just the "normal" ones.

STM  14,12,12(13)
hardly constitutes "doing funky save-area machinations".

Saving your caller's registers is a good practice, if for no other reason than 
to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

--
Tom Marchant

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

EZAFTPKS from Started task

[Joseph Reichman]

hI

 

I have been testing out a started task under TESTAUTH (it does APF
authorized command). In addition it uses EZAFTPKS to download a file to
windows, this works fine under TEST

 

When I know try to run the code I get the following abend

 

BPXP018I THREAD 1FD85002, IN PROCESS 16842778, ENDED

WITHOUT BEING UNDUBBED WITH COMPLETION CODE 840C1000

, AND REASON CODE 0001. 

 

After doing some research on EZAFTPKS it says that it has to have a OMVS
segment defined I am far from RACF expert but I am wondering if anyone has
had similar experiences and might be able to shed some light

 

Thanks 


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

Re: Unix-question

[Paul Gilmartin]

On Tue, 29 Aug 2017 12:14:27 -0500, John McKown wrote:

>On Tue, Aug 29, 2017 at 11:37 AM, scott Ford wrote:
>
>> I was reading through IBM Unix services manuals and have a pipe question..
>> If I as a STC ..issue a Unix command after a PIPE was established and
>> retrieve output of the
>> command,  ...
>
>​You can set the descriptor to be non-blocking using the BPX1FCT call.
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/fct.htm
>  ...
I wondered briefly, naively.whether popen() might be the simplest
approach to this problem.  Then I came to my senses and remembered,
it's  FILE * popen( ... ); and COBOL is probably not FILE*-savvy.
(Or is it?)  It's a pity there isn't a more basic popen() returning a
descriptor rather than a FILE*.

-- gil

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Bernd Oppolzer]

Would the following approach help?

From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.

The subtask does all the 64 bit AMODE switching (and return), and 
establishes
an ESTAE exit (or other technique) to handle errors that occur inside 
the subtask.
If errors occurs, you return information about the error to the C/C++ 
main task
(normal return, not percolate), which then can signal the error and 
activate
the LE error handling, as usual, so you can do your garbage collection 
tasks etc.


Kind regards

Bernd


Am 29.08.2017 um 19:01 schrieb Charles Mills:

On some further review, a separate "AMODE 64 ESTAE" won't do anything for me
(unless I am missing something). My existing ESTAE is working fine.

The issue at hand is "how do I get C/C++ to trigger a Signal routine." For
you assembler folks, a Signal routine is roughly equivalent to a retry
routine. In fact, I guess it is C's implementation of what under the covers
is LE's retry routine.

My business logic is all in C++ (and man am I happy with that! No more "oh
crap, I forgot to clear R2" type problems. But I digress). The problem at
hand is "I just S0C4'ed. How do I get into my cleanup logic and clean
everything up, write the appropriate diagnostics, etc.?" The answer should
be "by driving my Signal routine."

So what is failing is not "my" ESTAE, but the percolation to LE's ESTAE, or
rather, what happens after percolation in LE's recovery routine. I am not a
mind reader, but my guess is that LE is saying "the ABEND took place in
AMODE 64 code. That is not my problem. Don't drive the retry (Signal)
routine; percolate to MVS." That is the problem I want to solve.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

@Peter, thanks as always.

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

  L R3,SDWAXPAD   Load SDWA extension ptrs
  L R4,SDWAXEME-SDWAPTRS(,R4)   Load ptr to 64-bit regs
  USING SDWARC4,R4
*
  NISDWAPSW16+3,X'FE'
*
  LRR1,R9   SDWA
  SETRP RC=0Percolate!
*
NOSDWA   EQU   *
  DROP  R9,R4
*
RETURN   EQU   *
  LRR14,R8  Restore R14
  BRR14 Return

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs.

--
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: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Tom Marchant]

On Tue, 29 Aug 2017 15:59:53 -0400, Thomas David Rivers wrote:

>The doc seems ambiguous to me; which leads me down this path
>of doing funky save-area machinations to ensure that all registers
>are saved - not just the "normal" ones.

STM  14,12,12(13)
hardly constitutes "doing funky save-area machinations".

Saving your caller's registers is a good practice, if for no other reason than 
to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

-- 
Tom Marchant

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

ABEND 737-04 when creating and writing to multivolume data sets - non-SMS only?

[Kirk Wolf]

I've been working through some issues on a system that uses non-SMS
datasets, which mostly works the way I expected.

But I have noticed that something that odd works on SMS managed datasets
and volumes fails without SMS.   For example:


//GENER EXEC PGM=IEBGENER
//SYSUT1DD DSN=KIRK.TEST.MVOLIN,DISP=SHR  30 tracks of FB/80 data
//SYSUT2DD DSN=KIRK.TEST.MVOL,
//  DCB=(RECFM=FB,LRECL=80),
//  UNIT=(3390,2),
//  VOLUME=(,,,2,SER=(VPWRKE,VPWRKF)),
//  SPACE=(TRK,(1,1)),   // should use 15 1-trk ext on 2 vols
//  DISP=(NEW,CATLG)
//SYSPRINT  DD SYSOUT=*
//SYSIN DD DUMMY
//*

On a system with SMS managed datasets and volumes, this works fine.
But without SMS, it gets:

 IEC027I 737-04,IFG0194D,CRTMVOL,GENER,SYSUT2,0D35,VPWRKF,KIRK.TEST.MVOL

So it can't find the F1 DSCB on VPWRKF - the second volume.
I always figured that creating this was automatic, but maybe only with SMS
managed?

Other googles for ABEND737-04 point to issues with multi-volume IMS OSAM
datasets, where IBM seems to prescribe that you must first allocate each
volume (without cataloging) separately:

https://www.ibm.com/support/knowledgecenter/en/SSEPH2_13.1.0/com.ibm.ims13.doc.sdg/ims_sag42.htm

If this is just the way that it works, fine, but I was hoping that someone
on list could shed some light on this darkness.

Regards,

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

Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Thomas David Rivers]

Steve Smith wrote:


The doc isn't "wrong", it's just a bit overstated.  It's a good idea
to follow normal linkage conventions (well normal from 1970) and
they're encouraging that.  This is an ancient facility, and for all I
know it may have been a more vital requirement in the past.

Also, I have no insider's knowledge of how the system works (like
Mulder & Relson).  It's conceivable that things could change to where
you'll fail somehow if you don't preserve the registers.

I would (and do) just follow normal saving and restoring conventions
in an ETXR.  It certainly won't hurt.


sas


 


Hence my question... the "normal saving" from the Assembler
Services doc says that R14, R15, R0 and R1 don't need to be preserved,
*unless* documented otherwise.

The ATTACH doc says that the called function is responsible
for "saving and restoring the registers."

Does that mean "all" the registers - or the "normal" ones; is that
sentence documentation that all the registers need to be saved/restored;
or that the system doesn't care about saving R14, R15, R0 and R1
and only R2-R13 needs to be saved/restored?

The doc seems ambiguous to me; which leads me down this path
of doing funky save-area machinations to ensure that all registers
are saved - not just the "normal" ones.

  - Dave Rivers-


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: extended GDG implementation

[John Eells]

Pommier, Rex wrote:

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 
generation GDG limit.  We are running z/OS 2.2 so are eligible for the 
relaxation.  I know I need to make a change to the IGGCATx member to activate 
the capability and I need to add EXT to the GDG definition.  So here are my 
(rather basic) questions.

1.  Can I implement an IGGCATxx member short of an IPL?  I don't have one now, 
relying on the defaults, and I don't see anything in the INIT manual 
that indicates that I can implement this dynamically, sadly.

2.  Once it is active, can I use an IDCAMS ALTER to change between the old limit and an 
extended one?  I am positive the answer to this is "no, it can only be done at GDG 
definition time" but am hoping.

3.  Here's the scenario that has led me to this point.  We just discovered we have a tape 
based GDG defined with LIMIT(255) and we have had several generations fall off the end.  
This is data we need to recover.  Presuming the answer to question 2 is "no" as 
I strongly suspect, does anybody see an unsurmountable problem with (carefully) 
uncataloging all the tape generations, redefining the GDG base as extended with an 
appropriate limit, and recataloging all the generations, including the ones that have 
fallen off?




For (1), Managing Catalogs says, "The system applies IGGCATxx values at 
IPL time as well as at the restart of the Catalog Address Space."  You 
can restart Catalog using F CATALOG,RESTART.  Be aware that Catalog 
operations will be suspended for a bit while that happens.


For (2), I don't see an ALTER keyword that would do that, nor the 
Extended attribute (for GDGs) in the alterable attribute list, in Access 
Method Services Commands.


For (3), I don't, but I'd want to try a test case or two first!

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: extended GDG implementation

[Doug Henry]

On Tue, 29 Aug 2017 19:10:07 +, Pommier, Rex  
wrote:

>2.  Once it is active, can I use an IDCAMS ALTER to change between the old 
>limit and an extended one?  I am positive the >answer to this is "no, it can 
>only be done at GDG definition time" but am hoping.

>3.  Here's the scenario that has led me to this point.  We just discovered we 
>have a tape based GDG defined with LIMIT(255) >and we have had several 
>generations fall off the end.  This is data we need to recover.  Presuming the 
>answer to question 2 >is "no" as I strongly suspect, does anybody see an 
>unsurmountable problem with (carefully) uncataloging all the tape 
>>generations, redefining the GDG base as extended with an appropriate limit, 
>and recataloging all the generations, including >the ones that have fallen off?

>TIA - again!  

>Rex

For answer to part 2 and 3 see Marna Wallle's blog.  As always Marna gives good 
advice. 

http://www.share.org/blog/gdg-to-gdge-conversions

Doug

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

Re: SMFLIMxx parameter

[Jim Mulder]

 REGIONABOVE controls 31-bit addressable storage.  You cannot address
more than 2G with only 31 bits. 

  MEMLIMIT controls 64-bit addressable virtual storage.  It has nothing
to do with the amount of real memory you have installed.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


IBM Mainframe Discussion List  wrote on 
08/29/2017 12:12:37 PM:

> From: "Adams, Anne (DTI)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/29/2017 03:15 PM
> Subject: Re: SMFLIMxx parameter
> Sent by: IBM Mainframe Discussion List 
> 
> Hey Carmen!
> Yep, and things still don't work. However, if I change REGIONABOVE 
> to 2G (or whatever I have in SMFPRMxx) then It works just fine ... 
> except for the fact that the region size is only 2G ... and I want it 
all.
> 
> Anne R. Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst 
> 302.298.3196
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Carmen Vitullo
> Sent: Tuesday, August 29, 2017 11:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMFLIMxx parameter
> 
> Hi Anne, tell Everyone I said YO! 
> all the example I've seen show
> REGION  JOBNAME(*) SUBSYS(JES*,STC)
>REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
>SYSRESVABOVE(50M)  SYSRESVBELOW(512K) looks like the error is 
> pointing to the SYSRESVBELOW posssibly did you try reversing the 
> order and try again? 
> 
> 
> Carmen 
> 
> - Original Message -
> 
> From: "Anne Adams (DTI)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, August 29, 2017 10:47:04 AM
> Subject: Re: SMFLIMxx parameter 
> 
> Hey Steve - 
> 
> Here's how we set up SMFLIMxx 
> 
> REGION JOBNAME(*) SUBSYS(STC,JES2)
> REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
> SYSRESVBELOW(512K) SYSRESVABOVE(100M)
> MEMLIMIT(10P) 
> 
> If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size 
> remained, 2G. Likewise if we put 4G or 6G that was the maximum. 
> However if we put NOLIMIT, then it appeared to default to 2G. We 
> tried setting REGIONABOVE(4G) in SMFLIMxx and would get and error. 
> T SMFLIM=00
> IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB ASA008I ERROR IN 
> PARMLIB MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 VALUE IS NOT 
> VALID - OUT OF RANGE. 
> 
> What I want to have happen is when we put NOLIMIT, the default is 
> however much memory I have installed. Maybe I don't fully understand
> how this works. 
> 
> 
> Anne R. Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Steve
> Sent: Friday, August 18, 2017 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMFLIMxx parameter 
> 
> Do you have the IEF043I joblog message and the SMFLIMxx rules that 
> you could post? Along with whatever messages you get for the refusalto 
run... 
> 
> - Steve 
> 
> 
> 
> On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> > Hello Friends,
> > 
> > Has anyone had any success using (or diagnosing failures) when 
> using the SMFLIMxx parameter? We have a few CICS and database 
> regions and one unrepentant job that refuse to run. 
> > 
> > Anne R. Adams, CISSP
> > DTI, Systems Engineering
> > Sr. Mainframe Services Analyst
> > 302.298.3196
> > 



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

Re: extended GDG implementation

[Dyck, Lionel B. (TRA)]

I can't answer (1) or (2) but you should check out CBTTape File 951 from Nick 
Light - it has a tool called GDGP that will help 'migrate' from existing GDG's 
to the new extended GDG. Be careful using it with SMS managed datasets but for 
tape it should be fine as it will uncatalog, delete the GDG base, redefine the 
GDG, and recatalog the datasets. I haven't tried it on tape but see no reason 
that it shouldn't work.

As always with the CBTTape ymmv so experiment before using in production

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, August 29, 2017 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] extended GDG implementation

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 
generation GDG limit.  We are running z/OS 2.2 so are eligible for the 
relaxation.  I know I need to make a change to the IGGCATx member to activate 
the capability and I need to add EXT to the GDG definition.  So here are my 
(rather basic) questions.

1.  Can I implement an IGGCATxx member short of an IPL?  I don't have one now, 
relying on the defaults, and I don't see anything in the INIT manual 
that indicates that I can implement this dynamically, sadly.

2.  Once it is active, can I use an IDCAMS ALTER to change between the old 
limit and an extended one?  I am positive the answer to this is "no, it can 
only be done at GDG definition time" but am hoping.

3.  Here's the scenario that has led me to this point.  We just discovered we 
have a tape based GDG defined with LIMIT(255) and we have had several 
generations fall off the end.  This is data we need to recover.  Presuming the 
answer to question 2 is "no" as I strongly suspect, does anybody see an 
unsurmountable problem with (carefully) uncataloging all the tape generations, 
redefining the GDG base as extended with an appropriate limit, and recataloging 
all the generations, including the ones that have fallen off?

TIA - again!  

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  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: extended GDG implementation

[Jousma, David]

Rex,

See my >> comments below.

_
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 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, August 29, 2017 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: extended GDG implementation

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 
generation GDG limit.  We are running z/OS 2.2 so are eligible for the 
relaxation.  I know I need to make a change to the IGGCATx member to activate 
the capability and I need to add EXT to the GDG definition.  So here are my 
(rather basic) questions.

1.  Can I implement an IGGCATxx member short of an IPL?  I don't have one now, 
relying on the defaults, and I don't see anything in the INIT manual 
that indicates that I can implement this dynamically, sadly.  <>my storage 
guys say they rename the GDG's, fix the base, and rename them back.  I cant say 
Ive tried that, but that’s what they tell me.

TIA - again!  

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

extended GDG implementation

[Pommier, Rex]

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 
generation GDG limit.  We are running z/OS 2.2 so are eligible for the 
relaxation.  I know I need to make a change to the IGGCATx member to activate 
the capability and I need to add EXT to the GDG definition.  So here are my 
(rather basic) questions.

1.  Can I implement an IGGCATxx member short of an IPL?  I don't have one now, 
relying on the defaults, and I don't see anything in the INIT manual 
that indicates that I can implement this dynamically, sadly.

2.  Once it is active, can I use an IDCAMS ALTER to change between the old 
limit and an extended one?  I am positive the answer to this is "no, it can 
only be done at GDG definition time" but am hoping.

3.  Here's the scenario that has led me to this point.  We just discovered we 
have a tape based GDG defined with LIMIT(255) and we have had several 
generations fall off the end.  This is data we need to recover.  Presuming the 
answer to question 2 is "no" as I strongly suspect, does anybody see an 
unsurmountable problem with (carefully) uncataloging all the tape generations, 
redefining the GDG base as extended with an appropriate limit, and recataloging 
all the generations, including the ones that have fallen off?

TIA - again!  

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: Unix-question

[Lou Losee]

http://tldp.org/LDP/lpg/node11.html

examples using C

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Tue, Aug 29, 2017 at 12:51 PM, scott Ford  wrote:

> So my question is where do I find a example of a pipe call and retrieve
> ...this would help me
>
>
>
> On Tue, Aug 29, 2017 at 1:45 PM scott Ford  wrote:
>
> > Gil,
> > Can u talk off list ?
> >
> > On Tue, Aug 29, 2017 at 12:57 PM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> On 2017-08-29, at 10:37, scott Ford wrote:
> >> >
> >> > I was reading through IBM Unix services manuals and have a pipe
> >> question..
> >> > If I as a STC ..issue a Unix command after a PIPE was established and
> >> > retrieve output of the
> >> > command, i *think* the answer is "yes". If so in a Single Thread STC
> >> would
> >> > the STC wait for the response ?? or does it depend on your code..I am
> >> > dealing with LE Cobol and want to utilize the nice features of Unix
> >> which i
> >> > am somewhat familiar.
> >> >
> >> Many questions:
> >>
> >> How are you creating the pipe?  Named or unnamed?
> >>
> >> How are you issuing the UNIX command?
> >>
> >> Is it a shell command?
> >>
> >> Did you put it in background with the '&' operator?
> >>
> >> Are you reading the output with a nonblocking read?
> >>
> >> Are you depending on the system buffer (131kB, I believe)
> >> to circumvent deadlock?
> >>
> >> Are you using select() to be notified of available output?
> >>
> >> Did you close the input end of the pipe in the parent process
> >> space in order to be able to detect end of information?
> >>
> >> Are you using waitpid() on the child?
> >>
> >> -- gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > Scott Ford
> > IDMWORKS
> > z/OS Development
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: SMFLIMxx parameter

[Carmen Vitullo]

Hi Anne, I just tested your SMFLIM parms and they were successful on my sandbox 
2.2 system with my SMFPRM00 MEMLIMIT(6G) 



REGION JOBNAME(*) SUBSYS(STC,JES2) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVBELOW(512K) SYSRESVABOVE(100M) 
MEMLIMIT(10P) 



T SMFLIM=00 
IEE536I SMFLIM VALUE 00 NOW IN EFFECT 


D SMFLIM 

SMF LIMIT rules were last set at: 08/29/2017 13.06.57 
There are 1 REGION rules active on this system. 
0 REGION rules were excluded due to syntax errors. 
0 REGION rules were excluded due to SYSNAME filtering. 


- Original Message -

From: "Anne Adams (DTI)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 29, 2017 11:12:37 AM 
Subject: Re: SMFLIMxx parameter 

Hey Carmen! 
Yep, and things still don't work. However, if I change REGIONABOVE to 2G (or 
whatever I have in SMFPRMxx) then It works just fine ... except for the fact 
that the region size is only 2G ... and I want it all. 

Anne R. Adams, CISSP 
DTI, Systems Engineering 
Sr. Mainframe Services Analyst 
302.298.3196 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Tuesday, August 29, 2017 11:57 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMFLIMxx parameter 

Hi Anne, tell Everyone I said YO! 
all the example I've seen show 
REGION JOBNAME(*) SUBSYS(JES*,STC) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVABOVE(50M) SYSRESVBELOW(512K) looks like the error is pointing to the 
SYSRESVBELOW posssibly did you try reversing the order and try again? 


Carmen 

- Original Message - 

From: "Anne Adams (DTI)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 29, 2017 10:47:04 AM 
Subject: Re: SMFLIMxx parameter 

Hey Steve - 

Here's how we set up SMFLIMxx 

REGION JOBNAME(*) SUBSYS(STC,JES2) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVBELOW(512K) SYSRESVABOVE(100M) 
MEMLIMIT(10P) 

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G) in SMFLIMxx 
and would get and error. 
T SMFLIM=00 
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB ASA008I ERROR IN PARMLIB 
MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 VALUE IS NOT VALID - OUT OF RANGE. 

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works. 


Anne R. Adams, CISSP 
DTI, Systems Engineering 
Sr. Mainframe Services Analyst 
302.298.3196 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve 
Sent: Friday, August 18, 2017 9:20 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMFLIMxx parameter 

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post? Along with whatever messages you get for the refusal to run... 

- Steve 



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> Hello Friends, 
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run. 
> 
> Anne R. Adams, CISSP 
> DTI, Systems Engineering 
> Sr. Mainframe Services Analyst 
> 302.298.3196 
> 
> 
> -- 
> 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 

-- 
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: SMFLIMxx parameter

[Chris Hoelscher]

Greedy aren't you .


Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Adams, Anne (DTI)
Sent: Tuesday, August 29, 2017 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMFLIMxx parameter

Hey Carmen!
Yep, and things still don't work. However, if I change REGIONABOVE to 2G (or 
whatever I have in SMFPRMxx) then It works just fine ... except for the fact 
that the region size is only 2G ... and I want it all.

Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst 
302.298.3196


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, August 29, 2017 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFLIMxx parameter

Hi Anne, tell Everyone I said YO! 
all the example I've seen show
REGION  JOBNAME(*) SUBSYS(JES*,STC)
   REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
   SYSRESVABOVE(50M)  SYSRESVBELOW(512K) looks like the error is pointing to 
the SYSRESVBELOW posssibly did you try reversing the order and try again? 


Carmen 

- Original Message -

From: "Anne Adams (DTI)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, August 29, 2017 10:47:04 AM
Subject: Re: SMFLIMxx parameter 

Hey Steve - 

Here's how we set up SMFLIMxx 

REGION JOBNAME(*) SUBSYS(STC,JES2)
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
SYSRESVBELOW(512K) SYSRESVABOVE(100M)
MEMLIMIT(10P) 

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G) in SMFLIMxx 
and would get and error. 
T SMFLIM=00
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB ASA008I ERROR IN PARMLIB 
MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 VALUE IS NOT VALID - OUT OF RANGE. 

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works. 


Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst
302.298.3196 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Friday, August 18, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFLIMxx parameter 

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post? Along with whatever messages you get for the refusal to run... 

- Steve 



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> Hello Friends,
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run. 
> 
> Anne R. Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196
> 
> 
> --
> 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

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame 

Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Ed Jaffe]

On 8/29/2017 6:07 AM, Steve Smith wrote:

Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.


I was astonished to learn recently that ETXR routines are entered in 
problem state even if the ATTACHX is issued by a supervisor state 
caller. Talk about inconvenient!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Unix-question

[scott Ford]

So my question is where do I find a example of a pipe call and retrieve
...this would help me



On Tue, Aug 29, 2017 at 1:45 PM scott Ford  wrote:

> Gil,
> Can u talk off list ?
>
> On Tue, Aug 29, 2017 at 12:57 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On 2017-08-29, at 10:37, scott Ford wrote:
>> >
>> > I was reading through IBM Unix services manuals and have a pipe
>> question..
>> > If I as a STC ..issue a Unix command after a PIPE was established and
>> > retrieve output of the
>> > command, i *think* the answer is "yes". If so in a Single Thread STC
>> would
>> > the STC wait for the response ?? or does it depend on your code..I am
>> > dealing with LE Cobol and want to utilize the nice features of Unix
>> which i
>> > am somewhat familiar.
>> >
>> Many questions:
>>
>> How are you creating the pipe?  Named or unnamed?
>>
>> How are you issuing the UNIX command?
>>
>> Is it a shell command?
>>
>> Did you put it in background with the '&' operator?
>>
>> Are you reading the output with a nonblocking read?
>>
>> Are you depending on the system buffer (131kB, I believe)
>> to circumvent deadlock?
>>
>> Are you using select() to be notified of available output?
>>
>> Did you close the input end of the pipe in the parent process
>> space in order to be able to detect end of information?
>>
>> Are you using waitpid() on the child?
>>
>> -- gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unix-question

[scott Ford]

Gil,
Can u talk off list ?

On Tue, Aug 29, 2017 at 12:57 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2017-08-29, at 10:37, scott Ford wrote:
> >
> > I was reading through IBM Unix services manuals and have a pipe
> question..
> > If I as a STC ..issue a Unix command after a PIPE was established and
> > retrieve output of the
> > command, i *think* the answer is "yes". If so in a Single Thread STC
> would
> > the STC wait for the response ?? or does it depend on your code..I am
> > dealing with LE Cobol and want to utilize the nice features of Unix
> which i
> > am somewhat familiar.
> >
> Many questions:
>
> How are you creating the pipe?  Named or unnamed?
>
> How are you issuing the UNIX command?
>
> Is it a shell command?
>
> Did you put it in background with the '&' operator?
>
> Are you reading the output with a nonblocking read?
>
> Are you depending on the system buffer (131kB, I believe)
> to circumvent deadlock?
>
> Are you using select() to be notified of available output?
>
> Did you close the input end of the pipe in the parent process
> space in order to be able to detect end of information?
>
> Are you using waitpid() on the child?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unix-question

[John McKown]

On Tue, Aug 29, 2017 at 11:37 AM, scott Ford  wrote:

> Guys/Gals:
>
> I was reading through IBM Unix services manuals and have a pipe question..
> If I as a STC ..issue a Unix command after a PIPE was established and
> retrieve output of the
> command, i *think* the answer is "yes". If so in a Single Thread STC would
> the STC wait for the response ?? or does it depend on your code..I am
> dealing with LE Cobol and want to utilize the nice features of Unix which i
> am somewhat familiar.
>

​You can set the descriptor to be non-blocking using the BPX1FCT call.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/fct.htm

When you use the F_SETL option to set the file attribute to include the
O_NONBLOCK. When you do a read, BPX1RED, on this file descriptor, you will
get an EAGAIN response instead of waiting. Or you could use BPX1POL to see
if data can be read from (or written to) the given file descriptor without
waiting.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/pol.htm

You could also use the BPX1SEL (select) call to see which FDs, if any, have
data available. If you are used to do BSAM READ statements where you can
WAIT on an ECB, the BPX1SEL can work in a similar manner.

I am not aware of any way to have a "exit routine" be scheduled as a
"signal" that data is available to be read, or written, without blocking.
IBM UNIX does not implement asynchronous I/O in UNIX.



>
> Regards,
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>


-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

> Just compile and link the C code as 64-bit.

That is a HUGE "just." This is tens of thousands of lines of C++ code, many
called library routines, and many linked-in atomic assembler functions. Not
a small "just" at all.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Tuesday, August 29, 2017 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

On some further review, a separate "AMODE 64 ESTAE" won't do anything for me
(unless I am missing something). My existing ESTAE is working fine.

The issue at hand is "how do I get C/C++ to trigger a Signal routine." For
you assembler folks, a Signal routine is roughly equivalent to a retry
routine. In fact, I guess it is C's implementation of what under the covers
is LE's retry routine.

My business logic is all in C++ (and man am I happy with that! No more "oh
crap, I forgot to clear R2" type problems. But I digress). The problem at
hand is "I just S0C4'ed. How do I get into my cleanup logic and clean
everything up, write the appropriate diagnostics, etc.?" The answer should
be "by driving my Signal routine."

So what is failing is not "my" ESTAE, but the percolation to LE's ESTAE, or
rather, what happens after percolation in LE's recovery routine. I am not a
mind reader, but my guess is that LE is saying "the ABEND took place in
AMODE 64 code. That is not my problem. Don't drive the retry (Signal)
routine; percolate to MVS." That is the problem I want to solve.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

@Peter, thanks as always. 

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

 L R3,SDWAXPAD   Load SDWA extension ptrs
 L R4,SDWAXEME-SDWAPTRS(,R4)   Load ptr to 64-bit regs
 USING SDWARC4,R4
*  
 NISDWAPSW16+3,X'FE'
*
 LRR1,R9   SDWA
 SETRP RC=0Percolate!
*
NOSDWA   EQU   *
 DROP  R9,R4 
* 
RETURN   EQU   *
 LRR14,R8  Restore R14
 BRR14 Return

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs. 

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

Re: SMFLIMxx parameter

[Carmen Vitullo]

Hum, I've not tried using SMFLIM yet, now you have me wanting to play around 
myself, maybe the 2G limit in SMFPRM is a gotya :) 
sorry I can't be more help, take care Anne 


Carmen 




- Original Message -

From: "Anne Adams (DTI)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 29, 2017 11:12:37 AM 
Subject: Re: SMFLIMxx parameter 

Hey Carmen! 
Yep, and things still don't work. However, if I change REGIONABOVE to 2G (or 
whatever I have in SMFPRMxx) then It works just fine ... except for the fact 
that the region size is only 2G ... and I want it all. 

Anne R. Adams, CISSP 
DTI, Systems Engineering 
Sr. Mainframe Services Analyst 
302.298.3196 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Tuesday, August 29, 2017 11:57 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMFLIMxx parameter 

Hi Anne, tell Everyone I said YO! 
all the example I've seen show 
REGION JOBNAME(*) SUBSYS(JES*,STC) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVABOVE(50M) SYSRESVBELOW(512K) looks like the error is pointing to the 
SYSRESVBELOW posssibly did you try reversing the order and try again? 


Carmen 

- Original Message - 

From: "Anne Adams (DTI)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 29, 2017 10:47:04 AM 
Subject: Re: SMFLIMxx parameter 

Hey Steve - 

Here's how we set up SMFLIMxx 

REGION JOBNAME(*) SUBSYS(STC,JES2) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVBELOW(512K) SYSRESVABOVE(100M) 
MEMLIMIT(10P) 

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G) in SMFLIMxx 
and would get and error. 
T SMFLIM=00 
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB ASA008I ERROR IN PARMLIB 
MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 VALUE IS NOT VALID - OUT OF RANGE. 

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works. 


Anne R. Adams, CISSP 
DTI, Systems Engineering 
Sr. Mainframe Services Analyst 
302.298.3196 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve 
Sent: Friday, August 18, 2017 9:20 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMFLIMxx parameter 

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post? Along with whatever messages you get for the refusal to run... 

- Steve 



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> Hello Friends, 
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run. 
> 
> Anne R. Adams, CISSP 
> DTI, Systems Engineering 
> Sr. Mainframe Services Analyst 
> 302.298.3196 
> 
> 
> -- 
> 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 

-- 
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: Unix-question

[Paul Gilmartin]

On 2017-08-29, at 10:37, scott Ford wrote:
> 
> I was reading through IBM Unix services manuals and have a pipe question..
> If I as a STC ..issue a Unix command after a PIPE was established and
> retrieve output of the
> command, i *think* the answer is "yes". If so in a Single Thread STC would
> the STC wait for the response ?? or does it depend on your code..I am
> dealing with LE Cobol and want to utilize the nice features of Unix which i
> am somewhat familiar.
>  
Many questions:

How are you creating the pipe?  Named or unnamed?

How are you issuing the UNIX command?

Is it a shell command?

Did you put it in background with the '&' operator?

Are you reading the output with a nonblocking read?

Are you depending on the system buffer (131kB, I believe)
to circumvent deadlock?

Are you using select() to be notified of available output?

Did you close the input end of the pipe in the parent process
space in order to be able to detect end of information?

Are you using waitpid() on the child?

-- gil

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

Re: Message IRX0006I running an edit macro CLIST

[Jesse 1 Robinson]

I have no stake in defending the JEM CLIST, but AFAIK 'ISREDIT MACRO' is 
required in order to run it from the command line with just 'jem'. For better 
or for worse, that's how people use the product. You're in edit on a JCL 
member. Before submitting, you execute JEM to increase your chances of getting 
a clean run. It does more than check JCL syntax. It also tries to check that 
data sets referred to actually exist and that in general the logic flow is at 
least superficially valid. Invoked as simply as possible. 

PROC is not required for this function. Up to now, PROC never got in the way of 
successful execution. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Monday, August 28, 2017 6:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: :Re: Message IRX0006I running an edit macro CLIST

FWIW

The oddity is that there are *no* edit macro statements after "ISREDIT MACRO 
(PARMSTR)". So why is an edit macro declared in the Clist?
 
E.g. "ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.can be issued directly from 
the Clist proc and does not need an edit macro to do that.
 
Sure, edit macros are normally invoked from the command line in edit mode. But 
they can also be invoked by Clist and REXX procs, and then not from the command 
line. So if JEM is a Clist that in turn invokes an edit macro, then 'TSO JEM + 
any parms' would be used to invoke JEM as a Clist (and ISPF option 6 could 
invoke it simply as 'JEM + any parms'). So, is JEM meant to be invoked as a 
Clist ("PROC 0 ...") or as an edit macro ("ISREDIT MACRO ()")?
 
I give up.
 
Cheers, CP
 

On 28/08/2017 15:52, Jesse 1 Robinson wrote:
> That is exactly the case. Like most (maybe all) edit macros), JEM is 
> executed directly on the command line. Running it as TSO command (tso 
> jem) would fail to establish the proper connection to ISPF. I tried 
> that and got
>
> EDIT MACRO ERROR
> EDIT MACRO INITIALIZATION FAILURE.  CHECK EDIT MACRO CLIST.
>
> I did not see Paul Feller's post except as quoted by CM Poncelet. As CM 
> notes, there are two parms: DSJNAME and PARMSTR. It seems odd that one is 
> defined on the PROC statement and the other on the ISREDIT MACRO statement, 
> but that's the way it's supplied to the customer. 
>
> I have no problem learning that an old loophole has been closed. But closed 
> is closed, and what fails in one place should fail everywhere with the fix is 
> place. The person who first reported the problem here is a true mainframe 
> veteran. He uses JEM more than anyone else I know. 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Sunday, August 27, 2017 8:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Message IRX0006I running an edit macro CLIST
>
> Typically the user is EDITing a PDS Member with JCL and enters JEM on 
> the command line
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of CM Poncelet
>> Sent: Sunday, August 27, 2017 7:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Message IRX0006I running an edit macro CLIST
>>
>> There are two parms for this Clist: DSJNAME and PARMSTR. How is JEM invoked?
>> (E.g. it could be invoked as "TSO JEM HLQ.DSJN1.THEREST MACPARM2".)
>>
>> On 27/08/2017 18:25, Feller, Paul wrote:
>>> One last comment.  We run the same software and have not had an 
>>> issue in
>> three different SYSPLEX environments.  I looked to the most recent 
>> versions of the software we have.  The JEM CLIST is shipped that way from 
>> the vendor.
>> Very interesting.
>>>
>>> BROWSESYSI.JOBSCAN.R790.AJJSCLST.HS(JEM) - 01. Line 00 Col 001
>> 080
>>>  Command ===>  Scroll ===>
>> CSR
>>> * Top of Data
>> *
>>>   PROC 0  DJSNAME(X.X)
>>>   CONTROL END(ENDO) NOMSG NOFLUSH
>>> /*CONTROL END(ENDO) MSG LIST CONLIST SYMLIST NOFLUSH /*S80725*/
>>>   ISREDIT MACRO (PARMSTR)
>>>
>>>   IF  = (X.X) THEN +
>>> DO
>>> ISPEXEC SETMSG MSG(JM022R)/*JTE30780*/
>>> GOTO ENDING
>>> ENDO
>>>
>>> /*    ALLOCATE RUN CONTROL LIBRARY
>>>ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)   /*JTE30780*/
>>>IF  NE 0 THEN +
>>>  DO
>>>SET  

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Steve Smith]

Answering anyway, even if *I'm* neither you or me :-):  FRR is
generally only appropriate when you have no other choice.  But I've
recently implemented an ARR, which is purportedly a higher-performing
alternative to ESTAE[X].  The IEAARR macro invokes the protected
routine, so it replaces your CALL/LINK/whatever.  It fit in nicely for
my situation.

The IEAARR macro itself is ridiculous.  Just grimace and bear it.

sas

On Tue, Aug 29, 2017 at 11:12 AM, Charles Mills  wrote:
> @Peter, thanks as always.
>
> I wonder if perhaps FRR would be
> appropriate. (Not a question for you; a question for me.)
>
>

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

Unix-question

[scott Ford]

Guys/Gals:

I was reading through IBM Unix services manuals and have a pipe question..
If I as a STC ..issue a Unix command after a PIPE was established and
retrieve output of the
command, i *think* the answer is "yes". If so in a Single Thread STC would
the STC wait for the response ?? or does it depend on your code..I am
dealing with LE Cobol and want to utilize the nice features of Unix which i
am somewhat familiar.

Regards,
-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: SMFLIMxx parameter

[Adams, Anne (DTI)]

Hey Carmen!
Yep, and things still don't work. However, if I change REGIONABOVE to 2G (or 
whatever I have in SMFPRMxx) then It works just fine ... except for the fact 
that the region size is only 2G ... and I want it all.

Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst 
302.298.3196


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, August 29, 2017 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFLIMxx parameter

Hi Anne, tell Everyone I said YO! 
all the example I've seen show
REGION  JOBNAME(*) SUBSYS(JES*,STC)
   REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
   SYSRESVABOVE(50M)  SYSRESVBELOW(512K) looks like the error is pointing to 
the SYSRESVBELOW posssibly did you try reversing the order and try again? 


Carmen 

- Original Message -

From: "Anne Adams (DTI)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, August 29, 2017 10:47:04 AM
Subject: Re: SMFLIMxx parameter 

Hey Steve - 

Here's how we set up SMFLIMxx 

REGION JOBNAME(*) SUBSYS(STC,JES2)
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
SYSRESVBELOW(512K) SYSRESVABOVE(100M)
MEMLIMIT(10P) 

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G) in SMFLIMxx 
and would get and error. 
T SMFLIM=00
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB ASA008I ERROR IN PARMLIB 
MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 VALUE IS NOT VALID - OUT OF RANGE. 

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works. 


Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst
302.298.3196 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Friday, August 18, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFLIMxx parameter 

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post? Along with whatever messages you get for the refusal to run... 

- Steve 



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> Hello Friends,
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run. 
> 
> Anne R. Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196
> 
> 
> --
> 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

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

Re: SMFLIMxx parameter

[Carmen Vitullo]

Hi Anne, tell Everyone I said YO! 
all the example I've seen show 
REGION  JOBNAME(*) SUBSYS(JES*,STC)
   REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
   SYSRESVABOVE(50M)  SYSRESVBELOW(512K) looks like the error is pointing to 
the SYSRESVBELOW posssibly 
did you try reversing the order and try again? 


Carmen 

- Original Message -

From: "Anne Adams (DTI)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 29, 2017 10:47:04 AM 
Subject: Re: SMFLIMxx parameter 

Hey Steve - 

Here's how we set up SMFLIMxx 

REGION JOBNAME(*) SUBSYS(STC,JES2) 
REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) 
SYSRESVBELOW(512K) SYSRESVABOVE(100M) 
MEMLIMIT(10P) 

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G) in SMFLIMxx 
and would get and error. 
T SMFLIM=00 
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB 
ASA008I ERROR IN PARMLIB MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 
VALUE IS NOT VALID - OUT OF RANGE. 

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works. 


Anne R. Adams, CISSP 
DTI, Systems Engineering 
Sr. Mainframe Services Analyst 
302.298.3196 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve 
Sent: Friday, August 18, 2017 9:20 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMFLIMxx parameter 

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post? Along with whatever messages you get for the refusal to run... 

- Steve 



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote: 
> Hello Friends, 
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run. 
> 
> Anne R. Adams, CISSP 
> DTI, Systems Engineering 
> Sr. Mainframe Services Analyst 
> 302.298.3196 
> 
> 
> -- 
> 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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

some years ago I Had to call a openssl library from Pl/1. the Openssl 
library was compiled using XPlink (31 Bit). it worked in the End. the only 
Problem was that there Had to be a Interface Module doing a dynamic fetch 
on the XPlink object, because static linkage was Not possible. And Posix 
(on) was needed. But No Problems with Switching enclaves etc.



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: John McKown
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 
assembler?
Datum: 29.08.2017, 17:34 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





On Tue, Aug 29, 2017 at 10:28 AM, Don Poitras 
> ; wrote:

> But you _can_ address data above the bar in "pure" C. Just compile and 
link
> the C code as 64-bit.
>

I've no experience, but from what I've read, this is "CPU costly" in that
the 31 bit C is running in a "normal" (non-XPLINK) LE enclave whereas 64
bit C _must_ run in an XPLINK LE enclave. Starting and stopping the XPLINK
LE enclave is "expensive", again from what I've read. Of course, with some
hard work, I think it might be possible to use a CEEPIPI to create and
maintain an XPLINK 64 bit LE enclave and dynamically swap between the LE
enclaves.

--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: SMFLIMxx parameter

[Adams, Anne (DTI)]

Hey Steve -

Here's how we set up SMFLIMxx

REGION JOBNAME(*) SUBSYS(STC,JES2) 
  REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT)
  SYSRESVBELOW(512K) SYSRESVABOVE(100M)
  MEMLIMIT(10P)

If we left SMFPRMxx MEMLIMIT(2G) then the maximum region size remained, 2G. 
Likewise if we put 4G or 6G that was the maximum. However if we put NOLIMIT, 
then it appeared to default to 2G. We tried setting REGIONABOVE(4G)  in 
SMFLIMxx and would get and error. 
T SMFLIM=00  
IEE252I MEMBER SMFLIM00 FOUND IN SYS1.PARMLIB
ASA008I ERROR IN PARMLIB MEMBER=SMFLIM00 ON LINE 3, POSITION 14: 362 
VALUE IS NOT VALID - OUT OF RANGE.   

What I want to have happen is when we put NOLIMIT, the default is however much 
memory I have installed. Maybe I don't fully understand how this works.


Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst 
302.298.3196

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Friday, August 18, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFLIMxx parameter

Do you have the IEF043I joblog message and the SMFLIMxx rules that you could 
post?  Along with whatever messages you get for the refusal to run...

- Steve



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote:
> Hello Friends,
> 
> Has anyone had any success using (or diagnosing failures) when using the 
> SMFLIMxx parameter? We have a few CICS and database regions and one 
> unrepentant job that refuse to run.
> 
> Anne R. Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196
> 
> 
> --
> 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[John McKown]

On Tue, Aug 29, 2017 at 10:28 AM, Don Poitras  wrote:

> But you _can_ address data above the bar in "pure" C. Just compile and link
> the C code as 64-bit.
>

​I've no experience, but from what I've read, this is "CPU costly" in that
the 31 bit C is running in a "normal" (non-XPLINK) LE enclave whereas 64
bit C _must_ run in an XPLINK LE enclave. Starting and stopping the XPLINK
LE enclave is "expensive", again from what I've read. Of course, with some
hard work, I think it might be possible to use a CEEPIPI to create and
maintain an XPLINK 64 bit LE enclave and dynamically swap between the LE
enclaves.​

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Don Poitras]

But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.

In article <007a01d320d9$fd9133a0$f8b39ae0$@mcn.org> you wrote:
> So far as I have seen, the documentation does not consider nor address the
> situation I have. It considers all-64-bit C with all-64-bit assembler, or
> all-31-bit C with all-31-bit assembler. I have 31-bit assembler with a few
> 64-bit instructions, one of which happened to S0C4. I suppose one (or IBM)
> could take the attitude "that's not allowed." But gee, why do people link
> from C to assembler to begin with? To do things they cannot do in pure C! I
> would say that addressing some data above the bar is a valid case of that.

> Charles


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Monday, August 28, 2017 11:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
> assembler?

> >If I had nothing better to do I would open an RFE on that. Even assuming
> AMODE 31, how can LE assume that the high halves of the registers are of no
> debugging value? 64-bit register arithmetic -- or even using the high halves
> of registers as a temporary holding area -- is a valid technique even in the
> absence of AMODE 64. The C/C++ compiler itself does so. 
>  

> Have a look at the "Language Environment Programming Guide for 64-bit
> Virtual Addressing Mode" manual, chapter "Chapter 21. Assembler
> considerations". It has some description about AMODE 64 assembler. I browsed
> it quickly, only. It talks about XPLINK convention to be a prerequisite for
> AMODE 64 assembler in a LE supported way. I never did anything with XPLINK,
> so I cannot say how much effort this is, but maybe you can change your
> assembler code to be LE AMODE 64 compatible.
> While your "SDWA hack" seems to work (today), it is cheating, as you said
> yourself. May hurt you, or your customer in the future. 


> --
> Peter Hunkeler

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Tom Marchant]

On Tue, 29 Aug 2017 08:13:33 -0700, Charles Mills wrote:

>z/OS 2.12? I missed that too. I am really falling behind here.

ROFL. I meant z/OS 1.12. Thanks for pointing out my error.

-- 
Tom Marchant
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Tom Marchant
>Sent: Tuesday, August 29, 2017 7:32 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
>
>On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:
>
>>The ESTAEX SPIEOVERRIDE keyword ...
>
>That's a new one on me. Thanks, Peter! Looks like it was introduced with z/OS 
>2.12. Requires APF authorization though
>
>--
>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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

So far as I have seen, the documentation does not consider nor address the
situation I have. It considers all-64-bit C with all-64-bit assembler, or
all-31-bit C with all-31-bit assembler. I have 31-bit assembler with a few
64-bit instructions, one of which happened to S0C4. I suppose one (or IBM)
could take the attitude "that's not allowed." But gee, why do people link
from C to assembler to begin with? To do things they cannot do in pure C! I
would say that addressing some data above the bar is a valid case of that.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, August 28, 2017 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

>If I had nothing better to do I would open an RFE on that. Even assuming
AMODE 31, how can LE assume that the high halves of the registers are of no
debugging value? 64-bit register arithmetic -- or even using the high halves
of registers as a temporary holding area -- is a valid technique even in the
absence of AMODE 64. The C/C++ compiler itself does so. 
 

Have a look at the "Language Environment Programming Guide for 64-bit
Virtual Addressing Mode" manual, chapter "Chapter 21. Assembler
considerations". It has some description about AMODE 64 assembler. I browsed
it quickly, only. It talks about XPLINK convention to be a prerequisite for
AMODE 64 assembler in a LE supported way. I never did anything with XPLINK,
so I cannot say how much effort this is, but maybe you can change your
assembler code to be LE AMODE 64 compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said
yourself. May hurt you, or your customer in the future. 


--
Peter Hunkeler





--
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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

z/OS 2.12? I missed that too. I am really falling behind here.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, August 29, 2017 7:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:

>The ESTAEX SPIEOVERRIDE keyword ...

That's a new one on me. Thanks, Peter! Looks like it was introduced with z/OS 
2.12. Requires APF authorization though

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

@Peter, thanks as always. 

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

 L R3,SDWAXPAD   Load SDWA extension ptrs
 L R4,SDWAXEME-SDWAPTRS(,R4)   Load ptr to 64-bit regs
 USING SDWARC4,R4
*  
 NISDWAPSW16+3,X'FE'
*
 LRR1,R9   SDWA
 SETRP RC=0Percolate!
*
NOSDWA   EQU   *
 DROP  R9,R4 
* 
RETURN   EQU   *
 LRR14,R8  Restore R14
 BRR14 Return

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs. 

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

Re: Looking for mainframe shops Lexington/Cincinnati

[Dan @ Poodles]

“As God is my witness, I thought turkeys could fly.”

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, August 29, 2017 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for mainframe shops Lexington/Cincinnati

WKRP? 



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

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Tom Marchant]

On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:

>The ESTAEX SPIEOVERRIDE keyword ...

That's a new one on me. Thanks, Peter! Looks like it was introduced 
with z/OS 2.12. Requires APF authorization though

-- 
Tom Marchant

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

Re: IBM 650 wrote fiction?

[Jack J. Woehr]

Paul Gilmartin wrote:

On Tue, 29 Aug 2017 06:51:34 -0500, John McKown wrote:


http://www.theregister.co.uk/2017/08/29/ibm_1960s_story_writing_software/





This could explain Game of Thrones.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Steve Smith]

The doc isn't "wrong", it's just a bit overstated.  It's a good idea
to follow normal linkage conventions (well normal from 1970) and
they're encouraging that.  This is an ancient facility, and for all I
know it may have been a more vital requirement in the past.

Also, I have no insider's knowledge of how the system works (like
Mulder & Relson).  It's conceivable that things could change to where
you'll fail somehow if you don't preserve the registers.

I would (and do) just follow normal saving and restoring conventions
in an ETXR.  It certainly won't hurt.


sas

On Tue, Aug 29, 2017 at 9:32 AM, Thomas David Rivers  wrote:
> Steve Smith wrote:
>
>> You'll have to spell it as ETXR, and if by "offset" you mean offset
>> from 0, then sure.
>>
>> You can do what you want with the registers.  The ETXR runs under an
>> IRB on the mother task, so I'm not sure why any of them need to be
>> saved.
>>
>> Beyond that, I've no idea what you're planning on doing, but ETXRs
>> aren't normally suitable for doing much.
>>
>>
>> sas
>>
>
>
> Hmm - then why is the doc so clear that the ETXR (spelled right :-) )
> needs to save/restore the regs?
>
> Is the doc wrong?
> Regarding the use of it - I just want a notification that the subtask
> ended early (perhaps because of an abend.)
>
>   - Dave R. -
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
>
> --
> 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: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Thomas David Rivers]

Steve Smith wrote:


You'll have to spell it as ETXR, and if by "offset" you mean offset
from 0, then sure.

You can do what you want with the registers.  The ETXR runs under an
IRB on the mother task, so I'm not sure why any of them need to be
saved.

Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.


sas
 



Hmm - then why is the doc so clear that the ETXR (spelled right :-) )
needs to save/restore the regs?

Is the doc wrong?  


Regarding the use of it - I just want a notification that the subtask
ended early (perhaps because of an abend.)

  - Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: IBM 650 wrote fiction?

[Paul Gilmartin]

On Tue, 29 Aug 2017 06:51:34 -0500, John McKown wrote:

>http://www.theregister.co.uk/2017/08/29/ibm_1960s_story_writing_software/
> 
And a couple decades later:
https://en.wikipedia.org/wiki/Racter

-- gil

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

Re: Looking for mainframe shops Lexington/Cincinnati

[Allan Staller]

WKRP? 



::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: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Steve Smith]

You'll have to spell it as ETXR, and if by "offset" you mean offset
from 0, then sure.

You can do what you want with the registers.  The ETXR runs under an
IRB on the mother task, so I'm not sure why any of them need to be
saved.

Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.


sas

On Tue, Aug 29, 2017 at 9:02 AM, Binyamin Dissen
 wrote:
> As I believe that it gets control via SYNCH(X), you really do not need to save
> or restore any registers. Just exit by branching to the address that was
> contained in R14 when entered.
>
> It would be a bit of an integrity exposure for the task termination routine to
> trust your registers.
>
> On Tue, 29 Aug 2017 06:02:12 -0400 Thomas David Rivers 
> wrote:
>
> :>When you specify the EXTR= parameter on an ATTACH, you
> :>are indicating the offset of an exit to asynchoronously receive
> :>control when the sub-task ends.
> :>
> :>This exit is invoked as many are, in that a 72-byte save area
> :>is addressed by R13 for saving/restoring the registers.
> :>
> :>The documentation even goes on to say:
> :>
> :> "The exit routine is responsible for saving and restoring
> :>   registers".
> :>
> :>In the 'MVS Programming: Assembler Services Guide" in the
> :>section on linkage, called "Saving the calling program's registers"
> :>it says that saving registers involves saving R2 through R13
> :>"Unless otherwise defined by the individual interface".
> :>
> :>Has the one sentence in the EXTR description 'otherwise defined'
> :>that R14,R15,R0 and R1 also need to be saved; or is it referring
> :>tot he normal saving which would not preserve those?  It seems
> :>a little ambiguous to me.
> :>
> :>That is - in the case for an EXTR exit - do we need to also save/restore
> :>R14,R15,R0 and R1 - or are those "safe" to trash?  I'd like to use
> :>them to trampoline into a different environment if possible without
> :>having to do a "save-area dance".
> :>
> :>   - Thanks -
> :>   - Dave Rivers -
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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: ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Binyamin Dissen]

As I believe that it gets control via SYNCH(X), you really do not need to save
or restore any registers. Just exit by branching to the address that was
contained in R14 when entered.

It would be a bit of an integrity exposure for the task termination routine to
trust your registers.

On Tue, 29 Aug 2017 06:02:12 -0400 Thomas David Rivers 
wrote:

:>When you specify the EXTR= parameter on an ATTACH, you
:>are indicating the offset of an exit to asynchoronously receive
:>control when the sub-task ends.
:>
:>This exit is invoked as many are, in that a 72-byte save area
:>is addressed by R13 for saving/restoring the registers.
:>
:>The documentation even goes on to say:
:>
:> "The exit routine is responsible for saving and restoring
:>   registers".
:>
:>In the 'MVS Programming: Assembler Services Guide" in the
:>section on linkage, called "Saving the calling program's registers"
:>it says that saving registers involves saving R2 through R13
:>"Unless otherwise defined by the individual interface".
:>
:>Has the one sentence in the EXTR description 'otherwise defined'
:>that R14,R15,R0 and R1 also need to be saved; or is it referring
:>tot he normal saving which would not preserve those?  It seems
:>a little ambiguous to me.
:>
:>That is - in the case for an EXTR exit - do we need to also save/restore
:>R14,R15,R0 and R1 - or are those "safe" to trash?  I'd like to use
:>them to trampoline into a different environment if possible without
:>having to do a "save-area dance".
:>
:>   - Thanks -
:>   - Dave Rivers -

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Relson]

I do not pretend to know the answer to the initial question, but when 
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in 
the PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all 
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA 
anew for each recovey routine, from a protected copy so that changes made 
by one ESTAE routine are not visible to the next (there are likely some 
exceptions, but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting 
of some bit that an ESTAE routine changed, unless that routine is itself 
calling LE providing that SDWA. Oherwise, LE would have no idea that you 
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside 
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code 
with your own recovery and having that recovery field any problem 
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure 
that LE's (E)SPIE does not get control if a program interrupt occurs. 

Peter Relson
z/OS Core Technology Design


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

Re: Looking for mainframe shops Lexington/Cincinnati

[Todd Arnold]

I asked some IBM coworkers of mine who are located in Lexington.  Here's what 
they had to say:

"One person thought of the University of Kentucky here in Lexington. Also, in 
Central Kentucky, I know of NTT Data (Frankfort), Booz Allen (Radcliff), and 
Humana (Louisville). Louisville/Cincinnati probably hold out the most 
opportunities.

I did see this job posting for Fort Knox:

https://sts-openhire.silkroad.com/epostings/index.cfm?fuseaction=app.dspjob=1317_id=16728=1=3338

Army base in Fort Knox and vendors who facilitate such..."

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

IBM 650 wrote fiction?

[John McKown]

http://www.theregister.co.uk/2017/08/29/ibm_1960s_story_writing_software/

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: ISFPRMxx question

[גדי בן אבי]

Thanks Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Tuesday, August 29, 2017 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISFPRMxx question

Gadi,

If you take a look at the ISFPRM01 member in the SISFJCL dataset, this contains 
FLD and FLDENT statements for all supplied displays.

Note that for all new displays, SDSF only supports a single FLDLIST (i.e. there 
is not an alternate field list that can be invoked using the "?" primary 
command).

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Tuesday, August 29, 2017 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISFPRMxx question

Hi,

We are in the process of customizing a brand new z/OS v2.2 system.
The ISFPRMxx member that came with the Server Pac has FLD and FLDENT statements 
for the DA Display.

Is there a way to generate these statements for other displays, so we can 
customize them?
Yes, I know the list of fields is in the manual, but I am looking for something 
automatic.

Thanks

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

--
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 877.328.2932 
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
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: ISFPRMxx question

[Rob Scott]

Gadi,

If you take a look at the ISFPRM01 member in the SISFJCL dataset, this contains 
FLD and FLDENT statements for all supplied displays.

Note that for all new displays, SDSF only supports a single FLDLIST (i.e. there 
is not an alternate field list that can be invoked using the "?" primary 
command).

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Tuesday, August 29, 2017 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISFPRMxx question

Hi,

We are in the process of customizing a brand new z/OS v2.2 system.
The ISFPRMxx member that came with the Server Pac has FLD and FLDENT statements 
for the DA Display.

Is there a way to generate these statements for other displays, so we can 
customize them?
Yes, I know the list of fields is in the manual, but I am looking for something 
automatic.

Thanks

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

--
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 877.328.2932
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: Linking module in SMP/E with ++JCL

[Jousma, David]

I used to have an IGGPRE exit.  Here are the relevant parts of mine.

//SMPPTFIN  DD DATA,DLM=ZZ
++USERMOD(MSMS001) .  
++VER(Z038) FMID(HDZ1C10).
++SRC(IGGPRE00)  DISTLIB(AOSD0) . 
IGGPRE00 CSECT
IGGPRE00 AMODE 31 
IGGPRE00 RMODE 24 
.
.
.
 IEFUCBOB 
 CVT DSECT=YES
 END   IGGPRE00   
ZZ
//

Would do the assembly/linkedit automatic.
_
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 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, August 28, 2017 4:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Linking module in SMP/E with ++JCL

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello,
I am having problem applying a USERMOD when using SMP/E.
I have a ++JCLIN statement within the USERMOD to do a LINK.
The USERMOD RECEIVES and APPLYs okay, but the LINK is not done.
The JCL within the ++JCLIN statement is okay, I can run it outside of SMP/E and 
it LINKs successfully.

Can anyone tell me why the following usermod does not link.

++USERMOD (LM2TBT0)  
++VER (Z038) FMID(HDZ2210)   
++JCLIN. 
//IGGPRE00 JOB (SOFTN002),'IGGPRE00 ',   
// CLASS=K,TIME=5,NOTIFY=,MSGCLASS=X  
//*  
//* EDIT ASSEMBLE IGGPRE00 & LINK TO LPALIB  
//*  
//ACFLINK EXEC PGM=IEWL, ACF2 MODULE LINK PROCEDURE  
//PARM='RENT,LET,LIST,XREF,SIZE=(512K,96K)'  
//SYSLMOD DD DISP=SHR,DSN=SYS1.LPALIB
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(10,10))   
//SYSPRINT DD SYSOUT=*   
//ACFMOD DD DISP=SHR,DSN=SYS2A.CA.LINKLIB
//SYSLIN DD *
  INCLUDE ACFMOD(ACF$GCVT) 
  INCLUDE ACFMOD(ACF00GCB) 
  INCLUDE LPALIB(IGGPRE00) 
  ENTRY IGGPRE00   
  NAME IGGPRE00(R) 
++SRC(IGGPRE00) DISTLIB(AVPSSRC).  
IGGPRE00 TITLE 'DF/DS PREPROCESSING EXIT FOR NEW DASD ALLOCATION' 
  "  source statements "   

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Thomas David Rivers]

When you specify the EXTR= parameter on an ATTACH, you
are indicating the offset of an exit to asynchoronously receive
control when the sub-task ends.

This exit is invoked as many are, in that a 72-byte save area
is addressed by R13 for saving/restoring the registers.

The documentation even goes on to say:

"The exit routine is responsible for saving and restoring
  registers".

In the 'MVS Programming: Assembler Services Guide" in the
section on linkage, called "Saving the calling program's registers"
it says that saving registers involves saving R2 through R13
"Unless otherwise defined by the individual interface".

Has the one sentence in the EXTR description 'otherwise defined'
that R14,R15,R0 and R1 also need to be saved; or is it referring
tot he normal saving which would not preserve those?  It seems
a little ambiguous to me.

That is - in the case for an EXTR exit - do we need to also save/restore
R14,R15,R0 and R1 - or are those "safe" to trash?  I'd like to use
them to trampoline into a different environment if possible without
having to do a "save-area dance".

  - Thanks -
  - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

ISFPRMxx question

[גדי בן אבי]

Hi,

We are in the process of customizing a brand new z/OS v2.2 system.
The ISFPRMxx member that came with the Server Pac has FLD and FLDENT statements 
for the DA Display.

Is there a way to generate these statements for other displays, so we can 
customize them?
Yes, I know the list of fields is in the manual, but I am looking for something 
automatic.

Thanks

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: How to require all secure FTP except to one subnet?

[Mike Wawiorko]

Suspect you are missing this from your FTP(S) server's FTP.DATA file

TLSMECHANISM ATTLS

It is easy to force security for the z/OS FTPS server as you are in control and 
can code the likes of :
SECURE_FTP REQUIRED
TLSMECHANISM ATTLS
SECURE_CTRLCONN PRIVATE
SECURE_DATACONN PRIVATE

The big question is what do you do about the anarchy that is batch jobs 
invoking the z/OS FTP client with whatever they like in their FTP.DATA file.

Mike Wawiorko


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of SUBSCRIBE IBM-MAIN Mary Vollmer
Sent: 28 August 2017 17:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to require all secure FTP except to one subnet?


This mail originated from outside our organisation - mary_voll...@mgic.com

I am implementing TLS 1.2 via AT-TLS and have a requirement to secure all FTPs 
using this protocol except for the exchanges occurring via the hipersocket.

I am manually coding the policy since I don't have zOSMF configured.  In my 
policy I have a rule for my unsecure connections, coding both LocalAddr and 
RemoteAddr with that of our hipersocket subnet.  It has a priority of 100 and 
is first in the policy.  I also have a rule for secure connections with no 
LocalAddr or RemoteAddr with a priority of 10.

In my FTPDATA:
   When I specify SECURE_FTP REQUIRED, all unsecure attempts (inbound and 
outbound) fail - including those via the hipersocket.


   When I specify SECURE_FTP ALLOWED, all unsecure attempts (inbound and 
outbound) are successful - even those NOT using the hipersocket.  

I turned on tracing and see the rules selected are as I would have expected but 
it appears the SECURE_FTP parm in FTP data rules, regardless of what's in the 
policy.  

Does anyone know if it's possible to do what I am trying do to with one TCPIP 
stack?

Thanks,
Mary Vollmer 
 

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

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 Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: SPF Panels for TCP/IP (was HSM Query command) - EZANS RFE

[Mike Wawiorko]

It is a purely symbolic point at which IBM might realise that keeping it as 
'uncommitted candidate' rather than meeting the RFE is becoming embarrassing. 

I'm sure you all knew what I meant.

Mike Wawiorko 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: 28 August 2017 06:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SPF Panels for TCP/IP (was HSM Query command) - EZANS RFE


This mail originated from outside our organisation - edgould1...@comcast.net

> On Aug 27, 2017, at 5:10 PM, Ed Jaffe  wrote:
> 
> On 8/23/2017 1:27 AM, Mike Wawiorko wrote:
>> This is my RFE.
>> 
>> Currently 75 votes supporting it but only uncommitted candidate.
>> Can we get it to over a hundred votes?
> 
> What happens when you reach 100 votes?
> 
> —

He gets a lollipop.

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

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 Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: Linking module in SMP/E with ++JCL

[Binyamin Dissen]

On Mon, 28 Aug 2017 16:32:57 -0500 Fred Kaptein  wrote:

:>Sorry, there is a period in the ++USERMOD statement.
:>++USERMOD (LM2TBT0). 

:>There are no error messages, the USERMOD is RECEIVED and APPLIED 
successfully. However, it does not link.

:>SYSMOD STATUS REPORT FOR APPLY PROCESSING  SYSMODS APPLIED  - 
1
:>SYSMOD   STATUSTYPE  FMID

:>LM2TBT0  APPLIED   USERMOD   HDZ2210 

:>ELEMENT  ELEMENT ELEMENTCURRENTCURRENTDISTLIB  SYSLIB 
 ASSEM   LOAD   LMOD SYSMOD SYSMOD 
:>TYPENAME  STATUS  FMID  RMID  LIBRARY 
LIBRARY NAMES   MODULE  SYSLIB   NAME STATUS 
  
:>SRC IGGPRE00APPLIED HDZ2210LM2TBT0 AVPSSRC SMPSTS 
   IGGPRE00IGGPRE00  LPALIBLM2TBT0APPLIED

:>note there is no MOD element

Don't recall if ++SRC also causes a MOD member to be reported.

But why do you think it wasn't linked? Show the full SMPOUT and SMPRPT.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>If I had nothing better to do I would open an RFE on that. Even assuming AMODE 
>31, how can LE assume that the high halves of the registers are of no 
>debugging value? 64-bit register arithmetic -- or even using the high halves 
>of registers as a temporary holding area -- is a valid technique even in the 
>absence of AMODE 64. The C/C++ compiler itself does so.


Have a look at the "Language Environment Programming Guide for 64-bit Virtual 
Addressing Mode" manual, chapter "Chapter 21. Assembler considerations". It has 
some description about AMODE 64 assembler. I browsed it quickly, only. It talks 
about XPLINK convention to be a prerequisite for AMODE 64 assembler in a LE 
supported way. I never did anything with XPLINK, so I cannot say how much 
effort this is, but maybe you can change your assembler code to be LE AMODE 64 
compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said 
yourself. May hurt you, or your customer in the future.


--
Peter Hunkeler





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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>I believe that with AMODE 31 this should be possible (establishing another
ESTAE routine, when LE is active), because IIRC this is what I did when
calling C and PL/1 routines from APL ...



Is it possible? Yes.
Is it supported by LE? No. Read my comment on Charle's previous thread.


--
Peter Hunkeler

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