Re: Easiest way to share incore data between batch jobs
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 again! -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
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 (table base for example. There are some product that are just the tool to do this (like matrix that stores your data in a dataspace(s) and even enable writes to storage from a problem state programs). ITschak On Thu, Mar 23, 2017 at 8:22 PM, Victor Gil wrote: > 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- > > -- > 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 and/or dataspaces (Matrix from Expanse comes to mind). > Another alternative is to store the dataset in a common area (nay be above > the bar), and store the start and end addresses in single name-token pair. > you just need a loaded program and a search one. this fits for a none > updated file. > > HTH > ITschak > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|** An IT GRC for Legacy systems* *| Automated Security Readiness Reviews (SRR) **|* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
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 incognita"... > > -Victor- > > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
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. http://www.infodd.com/images/infodd/downloads/I33.pdf You can also do it from COBOL with the BPX1Mxx calls (like GT for get or AT for Attach), it can run unauthorized in keys 2, 8 and 9. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r1.bpxb100/mgt.htm Hope that helps. Denis. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
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- -- 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 and/or dataspaces (Matrix from Expanse comes to mind). Another alternative is to store the dataset in a common area (nay be above the bar), and store the start and end addresses in single name-token pair. you just need a loaded program and a search one. this fits for a none updated file. HTH ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
How about using Unix System Services shared memory and optionally semaphores? If found this, but it uses C. http://www.infodd.com/images/infodd/downloads/I33.pdf You can also do it from COBOL with the BPX1Mxx calls (like GT for get or AT for Attach), it can run unauthorized in keys 2, 8 and 9. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r1.bpxb100/mgt.htm Hope that helps. Denis. -Original Message- From: IronSphere by SecuriTeam Software To: IBM-MAIN Sent: Thu, Mar 23, 2017 6:25 pm 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 elapse. BTW, there are few products that store data in storage and/or dataspaces (Matrix from Expanse comes to mind). Another alternative is to store the dataset in a common area (nay be above the bar), and store the start and end addresses in single name-token pair. you just need a loaded program and a search one. this fits for a none updated file. HTH ITschak On Thu, Mar 23, 2017 at 5:52 PM, Victor Gil wrote: > 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 suggestion > was to use EXCI into a CICS region or call a DB2 stored procedure which > would act as a "server", but the question is - is there an easier way to > accomplish this in pure batch? I am familiar with the cross-memory access > but this would require heavy assembler coding, APF authorization, etc. all > of which we are trying to avoid. > > TIA! > -Victor- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|** An IT GRC for Legacy systems* *| Automated Security Readiness Reviews (SRR) **|* -- 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: Easiest way to share incore data between batch jobs
As someone else has already mentioned Hyperbatch. Here's a link to the manual. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idag200/hbatch.htm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 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 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 and/or dataspaces (Matrix from Expanse comes to mind). Another alternative is to store the dataset in a common area (nay be above the bar), and store the start and end addresses in single name-token pair. you just need a loaded program and a search one. this fits for a none updated file. HTH ITschak On Thu, Mar 23, 2017 at 5:52 PM, Victor Gil wrote: > 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 > suggestion was to use EXCI into a CICS region or call a DB2 stored > procedure which would act as a "server", but the question is - is > there an easier way to accomplish this in pure batch? I am familiar > with the cross-memory access but this would require heavy assembler > coding, APF authorization, etc. all of which we are trying to avoid. > > TIA! > -Victor- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|** An IT GRC for Legacy systems* *| Automated Security Readiness Reviews (SRR) **|* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 elapse. BTW, there are few products that store data in storage and/or dataspaces (Matrix from Expanse comes to mind). Another alternative is to store the dataset in a common area (nay be above the bar), and store the start and end addresses in single name-token pair. you just need a loaded program and a search one. this fits for a none updated file. HTH ITschak On Thu, Mar 23, 2017 at 5:52 PM, Victor Gil wrote: > 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 suggestion > was to use EXCI into a CICS region or call a DB2 stored procedure which > would act as a "server", but the question is - is there an easier way to > accomplish this in pure batch? I am familiar with the cross-memory access > but this would require heavy assembler coding, APF authorization, etc. all > of which we are trying to avoid. > > TIA! > -Victor- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|** An IT GRC for Legacy systems* *| Automated Security Readiness Reviews (SRR) **|* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
Hi, Are you thinking about something like Hyperbatch? https://goo.gl/xJkWB7 Thanks, Yifat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Victor Gil Sent: 23 March 2017 17: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 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 suggestion was to use EXCI into a CICS region or call a DB2 stored procedure which would act as a "server", but the question is - is there an easier way to accomplish this in pure batch? I am familiar with the cross-memory access but this would require heavy assembler coding, APF authorization, etc. all of which we are trying to avoid. TIA! -Victor- -- 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: Easiest way to share incore data between batch jobs
Or the newer caching capabilities of SMB (System Managed Buffering), which is reputed to be more efficient than BLSR. I have not personally tested that assertion in a real-world situation, so I can't say if it is true or not. Peter -Original Message- From: IBM Mainframe Discussion 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 type of buffering of the VSAM file to improve access and save on physical I/O? Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion 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 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 suggestion was to use EXCI into a CICS region or call a DB2 stored procedure which would act as a "server", but the question is - is there an easier way to accomplish this in pure batch? I am familiar with the cross-memory access but this would require heavy assembler coding, APF authorization, etc. all of which we are trying to avoid. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Easiest way to share incore data between batch jobs
Have you looked at RLS for VSAM? Data is held in CF structure. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Victor Gil > Sent: Thursday, March 23, 2017 8:52 AM > 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 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 suggestion was to > use EXCI into a CICS region or call a DB2 stored procedure which would act as > a "server", but the question is - is there an easier way to accomplish this in > pure batch? I am familiar with the cross-memory access but this would require > heavy assembler coding, APF authorization, etc. all of which we are trying to > avoid. > > TIA! > -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 type of buffering of the VSAM file to improve access and save on physical I/O? Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion 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 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 suggestion was to use EXCI into a CICS region or call a DB2 stored procedure which would act as a "server", but the question is - is there an easier way to accomplish this in pure batch? I am familiar with the cross-memory access but this would require heavy assembler coding, APF authorization, etc. all of which we are trying to avoid. TIA! -Victor- -- 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: Easiest way to share incore data between batch jobs
Can't that be done with a dataspace? https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa500/ieaa50022.htm -- Donald Grinsell, Systems Programmer Enterprise Technology Services Bureau SITSD/Montana Department of Administration 406.444.2983 (D) "Man is still the 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: 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 particular record with a given > key. > > I am a bit outdated in current systems services, so my first suggestion was > to use EXCI into a CICS region or call a DB2 stored procedure which would act > as a "server", but the question is - is there an easier way to accomplish > this in pure batch? I am familiar with the cross-memory access but this > would require heavy assembler coding, APF authorization, etc. all of which we > are trying to avoid. > > TIA! > -Victor- > > -- > 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
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 particular record with a given key. I am a bit outdated in current systems services, so my first suggestion was to use EXCI into a CICS region or call a DB2 stored procedure which would act as a "server", but the question is - is there an easier way to accomplish this in pure batch? I am familiar with the cross-memory access but this would require heavy assembler coding, APF authorization, etc. all of which we are trying to avoid. TIA! -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
