|
View previous topic :: View next topic
|
| Author |
Message |
anuj1411
New User
Joined: 22 Jul 2022
Posts: 3
Location: India
|
|
|
|
Hello,
We are building a cobol program that will be called from hundreds of jobs at the same time,
Call would be line shown below
Job A -> Cobol A -> My Cobol
Job B -> Cobol A -> Cobol B -> My Cobol and so on.
Each time my cobol program is being called it has to do some calculation and write to a file. Only write.
My cobol program could be called simultaneously by hundreds of callers. I used VSAM (KSDS) file for this with SHAREOPTIONS(3,3).
For testing I ran 4 Jobs simultaneously. 1, 2 or sometimes 3 of the jobs have an PUT error while writing to the VSAM file described below.
[Date] [JOBID] *IDAI1001E PUT FAILED, ERROR FOUND WHILE UPDATING THE INDEX 405
405 DSN: [Dsn of the file]
405 REASON: OUT OF SEQUENCE INDEX RECORD
As far as I know, and I know very little, the jobs would run fine with SHAREOPTIONS(3,3).
Also as I don't know which Jobs will call this program, I used BPXWDYN to dynamically allocate the file in COBOL in SHR mode.
I tried to search for this issue using IDAI1001E and came across IBM article but cant find sufficient information to solve this.
All help or insights would be welcome.
Thanks in advance. |
|
| Back to top |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2024
Location: USA
|
|
|
|
The real samples of your exact code are required:
- how do you create your VSAM dataset?
- how do you "write only" to your dataset?
- how do you choose the RID (the key) for your record(s)?
- are you overriding the same record from "hundreds of jobs", or adding new records for different jobs?
. . . . etc. etc. etc. . . . . . . . .
Without such details this is a dummy blah-blah-blah. |
|
| Back to top |
|
|
dneufarth
Active User
Joined: 27 Apr 2005
Posts: 420
Location: Inside the SPEW (Southwest Ohio, USA)
|
|
|
|
you must realize
| Code: |
Cross-region SHAREOPTIONS 3: The data set can be fully shared by any number of users. With this option, each user is responsible for maintaining both read and write integrity for the data the program accesses. This setting does not allow any type of non-RLS access when the data set is already open for RLS processing.
This option requires that the user's program use ENQ/DEQ to maintain data integrity while sharing the data set, including the OPEN and CLOSE processing. User programs that ignore the write integrity guidelines can cause VSAM program checks, lost or inaccessible records, uncorrectable data set failures, and other unpredictable results. This option places responsibility on each user sharing the data set. |
|
|
| Back to top |
|
|
anuj1411
New User
Joined: 22 Jul 2022
Posts: 3
Location: India
|
|
|
|
| Quote: |
how do you create your VSAM dataset?
|
1) The VSAM file is created seperately through a JCL using IDCAMS
DEF CL (NAME([DSN]) -
RECORDSIZE(316 316) -
BUFSP(74545) -
KEYS(39 0) -
FREESPACE(20 20) -
REUSE -
SHR(3 3) -
CYL(200 200) -
LOG(NONE) -
STORCLAS(SCCSLOW) -
SPEED) -
DATA -
(NAME([DSN].DATA) -
CISZ(2048)) -
INDEX -
(NAME([DSN].INDEX)-
CISZ(2048))
| Quote: |
| - how do you "write only" to your dataset? |
2) Record is written with just the WRITE keyword
WRITE Vsam-Record
| Quote: |
| how do you choose the RID (the key) for your record(s)? |
3) Key is the timestamp in below format concatenated with Jobname and calling program
20220722070436783307 [JOBNAME] [PROGRAM-NAME]
<------19 characters----><8 characters><8 characters>
| Quote: |
| - are you overriding the same record from "hundreds of jobs", or adding new records for different jobs? |
4) Adding new records for every job.
Sorry for the missing details in OP |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2024
Location: USA
|
|
|
|
Since it seems to be your very first attempt to "write to VSAM file", I suggest to begin from scratch.
First of all, run a unit test on your "My Cobol" program, running from a single test job, and writing at least several, or better multiple records to your VSAM.
If this test is successful, you can move forward after that.
The details of each step are needed, with exact code, and exact data written; not only abstract notes about your intentions...
P.S.
Step #1: Learn how to use the Code button when presenting your samples. |
|
| Back to top |
|
|
anuj1411
New User
Joined: 22 Jul 2022
Posts: 3
Location: India
|
|
|
|
Yes you are right, this is my first attempt,
| Quote: |
| If this test is successful, you can move forward after that. |
I have tested this and a single job was able to write all the records(around 16000) to the VSAM file successfully, the issue arises when the jobs are run in parallel. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
You did not implement any enqueue / dequeue logic in your COBOL program, yet you are surprised that the results you get are not what you predicted? Read dneufarth's post again about what shareoptions 3 means. What you are seeing is "unpredictable results" and IBM warns you that what you are doing will cause them. In other words, the results you are seeing are PRECISELY what you should see, according to IBM.
Unless and until you implement enqueue / dequeue logic, you will continue to have problems. And before you ask, IBM does not provide any enqueue / dequeue mechanism in COBOL. It is available for CICS programs but not batch COBOL. You'll have to find a way to implement the logic outside of COBOL. The method I've seen most often used is a subprogram in HLASM that is called from the COBOL program. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3053
Location: NYC,USA
|
|
|
|
You can set negative dependency in scheduling between the jobs.
Second how do you get the job name and program name in the same called module? Someone may have a typo in the job name if parm is used across the jobs, did you check that ? |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| anuj1411 wrote: |
| We are building a cobol program that will be called from hundreds of jobs at the same time, |
And which imbecile/incompetent PHB came up with this ludicrous "requirement", and more importantly, WHY? |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| prino wrote: |
| anuj1411 wrote: |
| We are building a cobol program that will be called from hundreds of jobs at the same time, |
And which imbecile/incompetent PHB came up with this ludicrous "requirement", and more importantly, WHY? |
Sounds like they are looking for a database solution without paying for a DBMS. That rarely ends well. |
|
| Back to top |
|
|
|
|
