This particular exit only looks at the commands issued (from consoles or jobs,
etc.) so the overhead is pretty small. I wanted to do a lot of optional work
at the time though so it made more sense to code things so that they told me
what to look at and I only looked at those commands (instead o
Brian,
I would agree it must be a lot of overhead looking at everything and then
having the code make the decision on what to do.
Especially in a System exit.
Scott
On Thu, May 16, 2019 at 12:19 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:
> HI,
>
> ALL commands issued at a consol
Peter/Clark,
Since we are a ISV, we try to intervene ourselves. My issue was on how to
do it. I know LE but I am faced with
we cant just convert to pure HLASM or even threaded C or C++ . So i have to
come up with an alternative solution
that works. We have been using Subpool 231 and it works fine
The choices are between saving the data yourself as you go, such as by
some sort of checkpoint or other method, or saving the data yourself after
the cancel (for which some sort of TERM=YES ESTAE-type recovery is
necessary) or not allowing the CANCEL (whether by intercepting CANCEL or
making th
HI,
ALL commands issued at a console or from a program or JCL are processed in the
command exit, whether they are JES or MVS commands or just random text typed on
the console.
When I developed our console message processing facility, I originally set it
up to run as a command exit and then cha
[Default] On 14 May 2019 11:23:01 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:
>All:
>
>I need to do some research on how job is cancelled via the Operator , Abend
>S222. I read through some of the Boston share doc of some time ago by Ed,
>Sam and Skip. Its great.
>I have
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that is a ge
ce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that
3-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Brian Westerman
Sent: Tuesday, May 14, 2019 10:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: LE question
I think that one of the CBTtape files has
I think that one of the CBTtape files has a program that is a generic abend
catcher and you execute it, passing it a parm of your program and it builds the
ESTAEX cushion around your program.
Alternatively, our SyzMPF/z product can intercept the cancel command and keep
it from being done when y
You can get control in an ESTAE exit after a cancel, you can't do a retry. If
your management isn't willing to rein in rogue operators than there is no good
solution. At one point checkpoint/restart might have helped, but how many
applications these days have only a single task?
--
Shmuel (Sey
I might be going off on a weird tangent. But if this is a started task,
instead of a program running in a batch job. And if it can be run as a
single step STC (not sure if this is a requirement). And it resides in an
APF authorized library. Then I would "register" the program in the SCHEDnn
member
scott Ford wrote:
>I need to do some research on how job is cancelled via the Operator , Abend
>S222. I read through some of the Boston share doc of some time ago by Ed, Sam
>and Skip. Its great.
>I have a job written in Cobol, this job has mission critical data storage in a
>table or array in
On Tue, 14 May 2019 14:22:37 -0400 scott Ford wrote:
:>I need to do some research on how job is cancelled via the Operator , Abend
:>S222. I read through some of the Boston share doc of some time ago by Ed,
:>Sam and Skip. Its great.
:>I have a question in regard to something that was stated on t
Good luck!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
scott Ford
Sent: Tuesday, May 14, 2019 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question
Alan,
I found some more info, we have a ECVT customer table entry. This sounds like
what I want.
Scott
mming: Extended Addressability Guide
>>
>> For the pendants on the list, please forgive me I have used incorrect
>> terminology.
>> Additional responses interspersed below.
>>
>> HTH,
>>
>> -Original Message-----
>> From: IBM Mainframe Discuss
BM Mainframe Discussion List On Behalf
> Of scott Ford
> Sent: Tuesday, May 14, 2019 1:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> Alan,
>
> Yes that was my thinking. What about persistence ?
> --> "common dataspace" vs. data
interspersed below.
HTH,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
scott Ford
Sent: Tuesday, May 14, 2019 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question
Alan,
Yes that was my thinking. What about persistence ?
--> "common dataspace"
Alan,
Yes that was my thinking. What about persistence ?
My question is there a dataspace that can be up without an owning running
TCB ?
Even it is require, if memory serves me another program if they need to
access the dataspace can query for the ALET ?
Can someone tell me if i am correct ?
Scot
Common Data Space? This is kind of what data spaces were invented for.
An init routine to run more or less @ IPL time to create, anchor and load the
data space.
Cobol to access/update the data via the dataspace
Optional routine to save the dataspace @ shutdown.
HTH,
-Original Message-
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hank Oerlemans
> Sent: Thursday, November 26, 2015 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> If it's that sensit
-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question
If it's that sensitive then linking in your own options module would be a good
idea.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.ed
If it's that sensitive then linking in your own options module would be a good
idea.
IMO
Hank
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO I
l of the options currently in effect.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, November 26, 2015 1:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE questio
Hank:
Much appreciated , exactly what I needed.
Regards,
Scott
IDMworks
On Thu, Nov 26, 2015 at 5:13 PM, Hank Oerlemans wrote:
> If you can assume R12 point to the CAA then:
>
> USING CEECAA,12
> USING CEEEDB,11
> USING CEEOCB,10
> L 11,CEECAAEDB
> L 10,CEEEDBOPTCB
> CEECAA
> CEEEDB
>
If you can assume R12 point to the CAA then:
USING CEECAA,12
USING CEEEDB,11
USING CEEOCB,10
L 11,CEECAAEDB
L 10,CEEEDBOPTCB
CEECAA
CEEEDB
CEEOCB
then use the following information to parse
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.
1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question
The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in
Parmlib or CEEOPT module in the code. Generally - one size fits all. In
CEEPRMxx are parms for CICS, Other, and I am not sure if there is another
delineat
The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in
Parmlib or
CEEOPT module in the code. Generally - one size fits all. In CEEPRMxx are
parms for CICS, Other, and I am not sure if there is another delineation or not.
So depending on the environment - I would start
m.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 10/03/2015 15:21
Subject: Re: LE Question
Sent by:IBM Mainframe Discussion List
On Tue, 10 Mar 2015 15:
On Tue, 10 Mar 2015 15:14:55 +, Martin Packer wrote:
>Hiperspace came along about 22 years before 64-bit ANYTHING, let alone
>64-Bit Virtual.
>
Nowadays, what advantage does hiperspace offer over 64-bit?
Performance, perhaps?
>From: Paul Gilmartin
>Date: 10/03/2015 12:29
>
>On Tue, 10 Ma
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 10/03/2015 12:29
Subject: Re: LE Question
Sent by:IBM Mainframe Discussion List
Alan:
I was thinking along the lines of what you suggested. cant suggest as a
ISV and developer to customers to use CICS or DB2 as a solution.
I personally think its overkill for a system type application which we
are..besides we handle sensitive security type data.
Regards,
Scott
On Tue, Mar 1
On Tue, 10 Mar 2015 09:37:42 +, Martin Packer wrote:
>More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 64-bit)
>memory map. That's the point of it.
>
Are you saying that it's there in case 64-bit is not enough?
-- gil
---
...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Scott Ford
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 10/03/2015 01:37
Subject:Re: LE Question
Sent by:IBM Mainframe Discussion List
Sam
itter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Alan Young
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 10/03/2015 06:44
Subject: Re: LE Question
Sent by:IBM Mainframe Discussion List
The C runtime I/O functions
On 10/03/2015 7:02 AM, Sam Siegel wrote:
64 bit memory is the cleanest in terms of using linear addresses. However,
if data needs to be referenced by COBOL, you will face problems. You might
need to copy back data to 31bit address space or other means.
dataspaces cannot be directly accesses by
One more potential option is the UNIX "shared memory" feature. I have not used
this in any of my own programs, so I cannot say for sure it is an option in
your case. Anyway, you might want to have a look.
There is a set of C functions called shmget(), shmat(), shmdt(), and shmctl().
A program cr
The C runtime I/O functions fopen(), fread(), fwrite(), etc. support
hiperspace data if the fopen() file mode parameter
type=memory(hiperspace) is specified.
The functions are callable from COBOL. You just have to setup the
parameters for what C expects and compile with NODYNAM. On our system
There are LOTS of other potential options here. In no particular order,
conceptually at least:
1. CICS TS's containers probably provide what you need, conveniently,
though you might have to "chunk" the data into containers of 2GB (or
smaller) so that 31-bit COBOL can "see" them (and all of them).
Sam,
Yeah I agree. I might have to stay with QSAM file until we can write and
test an API..
Thanks a lot,
As always much appreciated.
Regards,
Scott
On Monday, March 9, 2015, Sam Siegel wrote:
> OK ... that is a lot of data.
>
> Since an address space provides for just 2GB in the 31 bit rang
OK ... that is a lot of data.
Since an address space provides for just 2GB in the 31 bit range for code,
data and system code, you cannot get 3GB in there. You have the following
choices:
1) 1 or more data spaces
2) 64bit memory
3) some 31 bit data in current address space; remainder in dataspace
Sam,
2-3 G .
Regards,
Scott
On Monday, March 9, 2015, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:
>
> >How much data? 10meg? 100meg? 1gig?
> >
> How about 10 gig? None of those numbers would be unreasonab
On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:
>How much data? 10meg? 100meg? 1gig?
>
How about 10 gig? None of those numbers would be unreasonable
if COBOL supported 64-bit addressing. But IBM can't see the use
for that.
Of course if the data are large enough they go into page data se
How much data? 10meg? 100meg? 1gig?
On Mar 9, 2015 2:06 PM, "Scott Ford" wrote:
> Guys:
>
> I will have to read and try ..my question is how do i pass a lot of data
> ...a dataspace ? i would like to avoid dasd if I can ..
>
> Regards,
> Scott
>
> On Mon, Mar 9, 2015 at 12:29 PM, Sam Siegel w
Guys:
I will have to read and try ..my question is how do i pass a lot of data
...a dataspace ? i would like to avoid dasd if I can ..
Regards,
Scott
On Mon, Mar 9, 2015 at 12:29 PM, Sam Siegel wrote:
> Scott - You will need to pass the address of the heap variable back to
> COBOL. Then use se
A general answer is Yes. Heap data persists until you explicitly free it. Stack
data "pops" when you return from a called routine.
That's a general answer. I don't know your specifics, and everything I know
about pointers in COBOL could be engraved on the back of a postage stamp.
But in general
Scott - You will need to pass the address of the heap variable back to
COBOL. Then use set address of to associate the address with a COBOL
linkage section entry.
You may also need to take into consideration how LE clean's up the heap.
Depending on which heap the variable is created in, the life t
47 matches
Mail list logo
