|
View previous topic :: View next topic
|
| Author |
Message |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Cheers DBZ for clearing a few things I'd forgotten about  |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
one more thing. (one of those days when I am just full of stuff to say!)
The only way you will get true 24/7 vsam which now requires a batch update is to run your update via CICS.
my first CICS COBOL CALL of a non-cics module was
a modification of a batch banking system
(banks have to calculate interest (debit as well as credit) every day,
report it to GL,
as well as post transactions and adjust the balances,
in addition to the monthly/periodic statement generation.
reporting was done via ques, which the batch system could use
as well as read-only vsam.
since the code for doing all of that was already written (in batch)
we just wrote front-end (or wrapper) CICS modules,
to access the account records and present them to the batch modules
that we CALLed from the CICS modules.
Fortunately we had written the batch system to have i/o modules,
so, the i/o modules were changed to update pass-along-areas instead of vsam records.
at the end of the CALL (return to the CICS wrapper) the actual i/o was performed.
yes, it was somewhat daunting to insure that everything fell into separate 4k areas which were addressed by pointers.
but, we did not have to go to db2 vsn 2 (at that time).
As i understand it, the bank (actually, service center)
was able to wait until the late 90's before converting to db2,
by which time db2 was much better than vsn 2.
But, as an idea, get all vsam updating out-of-batch and into the online,
and the COBOL CALL of a non-cics module by a CICS module made that possible. |
|
| Back to top |
|
|
chetanambi
New User
Joined: 21 Jan 2012
Posts: 58
Location: India
|
|
|
|
Just an fyi.. As most of you gurus are telling BATCH job cannot access the file untill it is closed in CICS else job will go down with RC=8. Even 1st step of my job is to close the file in CICS and then it will process the file in next steps.
| Code: |
IKJ56241I DATA SET xxxxxx.xx.xxxx.xxxxxxxx NOT ALLOCATED
IKJ56241I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IDC0551I ** ENTRY xxxxx.xx.xxxx.xxxxxxxx NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
|
dbz/Bill,
| Quote: |
| The solution provided by Bill o'boyle concerning AOR/FOR allows for the easiest method of implementing data integrity in CICS. But, even that does not address the problem of concurrent batch/cics update. |
Could you please suggest the how can I use this FOR/AOR concept for better data integrity. File is defined in both the CICS regions with same properties. Note that none of our batch programs are updating the file concurrently but only 2 programs as mentioned earlier. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
go back and this time read VSAM Demystified
this thread has passed the point of giving help,
what you are now asking for is something that we all get paid to do.
Your sysprogrammers/cics support people are the ones that have to implement this.
If they can not, i as well as several others are available on a per-day fee (plus costs)
to advise/train your company personel. |
|
| Back to top |
|
|
chetanambi
New User
Joined: 21 Jan 2012
Posts: 58
Location: India
|
|
|
|
| Hmm.. Thanks a lot for your help and support... |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
I've used GSR (Global Shared Resources) in ISPF 3.4 imbedded in a "WHOHAS" or "WHOUSE" Rexx-Routine.
But, because GRS expands into an MVS/SVC, it should not be used directly in CICS, so you're back to the same dilemma; Multiple AOR's attempting to update a VSAM file concurrently.
From what I can determine (as I've said before), an FOR is your best bet. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Well in the past i did some ENQ/DEQ on a vsam ksds used by zillions of ISPF users, and did it on minor name the ksds key and the major name on a predefined name and used STEP,SYSTEM,SYSTEMS as environment.
Worked perfectly, but then it was not CICS and batch jobs running concurrently. |
|
| Back to top |
|
|
chetanambi
New User
Joined: 21 Jan 2012
Posts: 58
Location: India
|
|
|
|
| Quote: |
Well in the past i did some ENQ/DEQ on a vsam ksds used by zillions of ISPF users, and did it on minor name the ksds key and the major name on a predefined name and used STEP,SYSTEM,SYSTEMS as environment.
Worked perfectly, but then it was not CICS and batch jobs running concurrently. |
In our system also its not batch and CICS running currently to update the file but 2 CICS regions trying to update the file concurrently. We close the file in CICS before batch the processing.
| Quote: |
But, because GRS expands into an MVS/SVC, it should not be used directly in CICS, so you're back to the same dilemma; Multiple AOR's attempting to update a VSAM file concurrently.
From what I can determine (as I've said before), an FOR is your best bet. |
Yes. Multiple AOR's or CICS regions are attempting to update a VSAM file. I am reading bout AOR/FOR/DOR/TOR etc. I am going to try by shareoptions to (2,3) or with this FOR concept (by consulting tech personal). |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| dbzTHEdinosauer wrote: |
| good post Anuj, allows for misconceptions to be addressed. |
Hope it just allows to address them and does not induce them... |
|
| Back to top |
|
|
|
|
