I'd like to thank everyone responded to this quest. Very educational!
It looks like the team has decided to cache this file locally, i.e. in each and
every address space accessing data, so nothing exciting is going to transpire
this time around.
Ah, well, back to the daily routine...
Thanks
Hi Victor.
Why should it be a problem state program? the idea is a single load, many
reads, isn't it? after IPL, run a STC to load the data and create the
name-token pair. later on, all users can access the data. As I wrote in my
original response, there are several product that does that
I'll second Lizette's suggestion for RLS. It should do exactly what you
want with far less change and trouble.
On Thu, Mar 23, 2017 at 2:25 PM, Victor Gil
wrote:
> Thanks Denis, an interesting approach!
>
> Will have to do some reading as this is my "terra
Thanks Denis, an interesting approach!
Will have to do some reading as this is my "terra incognita"...
-Victor-
-
How about using Unix System Services shared memory and optionally semaphores?
If found this, but it uses C.
ITschak,
Really like this idea, could you please elaborate a bit - how would a
problem-state program load data in common area? It needs to be store-protected
to prevent overlays, so that would require the loader to be APF authorization,
no?
-Victor-
Subject: Re: Easiest way to share incore data between batch jobs
If your interest is sharing, CICS can store a complete vsam file in
dataspace using a standard IO routines (GET, PUT, POINT etc.). It is few
CICS parameters away and involves no code change. I am not sure that EXCI
will save you CPU or
Of IronSphere by SecuriTeam Software
Sent: Thursday, March 23, 2017 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Easiest way to share incore data between batch jobs
If your interest is sharing, CICS can store a complete vsam file in dataspace
using a standard IO routines (GET, PUT, POINT etc.). It is few
If your interest is sharing, CICS can store a complete vsam file in
dataspace using a standard IO routines (GET, PUT, POINT etc.). It is few
CICS parameters away and involves no code change. I am not sure that EXCI
will save you CPU or elapse. BTW, there are few products that store data in
storage
to share incore data between batch jobs
A co-worker suggested to save CPU by having one job to cache a VSAM file [which
is frequently looked up by multiple jobs] and introduce a new "look up" API to
"connect" to that job and locate a particular record with a given key.
I am a bit
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Feller, Paul
Sent: Thursday, March 23, 2017 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Easiest way to share incore data between batch jobs
Would it be just easier to look into something like BLSR (Batch Local Shared
Resources) or some other
bject: Easiest way to share incore data between batch jobs
>
> A co-worker suggested to save CPU by having one job to cache a VSAM file
> [which is frequently looked up by multiple jobs] and introduce a new "look up"
> API to "connect" to that job and locate a p
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Victor Gil
Sent: Thursday, March 23, 2017 10:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Easiest way to share incore data between batch jobs
A co-worker suggested to save CPU by having one job to cache a VSAM file [which
is frequently looked up
most extraordinary computer of all."
~ John F Kennedy
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Victor Gil
> Sent: Thursday, March 23, 2017 9:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Easi
A co-worker suggested to save CPU by having one job to cache a VSAM file [which
is frequently looked up by multiple jobs] and introduce a new "look up" API to
"connect" to that job and locate a particular record with a given key.
I am a bit outdated in current systems services, so my first
14 matches
Mail list logo