Re: Sharing data sets VSAM VB

2021-02-25 Thread Jeremy Nicoll 
On Thu, 25 Feb 2021, at 21:10, Paul Gilmartin wrote:
> On Thu, 25 Feb 2021 14:56:36 +, Jeremy Nicoll wrote:

> >...  Better, use several trailing steps and conditional jcl ...
> >
> That's *so* 20th Century.  Better, wrap the payload in a Rexx
> program that can do a SELECT on the completion code.

I don't think Joe's going to manage that.


Anyway, simple has some advantages.

Everyone understands the concept of renaming a file, and the 
original-named or renamed file is visible to everyone who might
need to manipulate those states (via ispf 3.4).  Renames that did
or didn't happen were also crystal clear in job logs.

I implemented systems that used variants on this mechanism
partly because it meant acf2 (in our case) could be used to 
allow/prevent people from resetting job states. 

-- 
Jeremy Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-25 Thread Paul Gilmartin 
On Thu, 25 Feb 2021 14:56:36 +, Jeremy Nicoll wrote:
> 
>> signal on NOVALUE
>> do CheckRC = 1
>> Address TSO “LISTBC” 
>> If rc == 0 then  Address tso “submit *”
>>Else address SYSCALL sleep 10
>> End CheckRC
>>  
Oops!  I left an endless loop.  I leave the termination condition
as an exercise for the student.

>The thing that worries me most about this is why it's thought that rc=0  
>from LISTBC tells you anything useful.
>
>...  Better, use several trailing steps and conditional jcl ...
>
That's *so* 20th Century.  Better, wrap the payload in a Rexx program
that can do a SELECT on the completion code.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-25 Thread Jeremy Nicoll 
On Thu, 25 Feb 2021, at 14:34, Paul Gilmartin wrote:
> On Thu, 25 Feb 2021 09:02:38 -0500, Joseph Reichman wrote:
 
> signal on NOVALUE
> do CheckRC = 1
> Address TSO “LISTBC” 
> If rc == 0 then  Address tso “submit *”
>Else address SYSCALL sleep 10
> End CheckRC
> 
> Have to check the Rexx syntax


Sorry, replying out of sequence...

The thing that worries me most about this is why it's thought that rc=0  
from LISTBC tells you anything useful.

If the purpose is to submit one job when the preceding one has ended, 
would it not be better at least to be able to tell if the preceding one ran
ok or not?

A simple solution is to create a flagfile, unique to each job, before that job
is submitted.  Delete the job's flagfile in its final step.  Better, use several
trailing steps and conditional jcl (so that only one of them runs) to rename
that flagfile to indicate if the job ran ok, or had bad step CCs, or abended.

Alternatively have each step append information into the flagfile, and that
way you can (also) record when the job started to run, what it did etc.

-- 
Jeremy Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-25 Thread Joseph Reichman 
Thank you so much 



> On Feb 25, 2021, at 9:34 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 25 Feb 2021 09:02:38 -0500, Joseph Reichman wrote:
> 
>> I am running all of this from Rex building JCL searching files there are a 
>> huge number of files so I break them up into different jobs 
>> 
>> What I am going to try is do 
>> Checkrc:
>> Address TSO “LISTBC” 
>> 
>> If rc == 0 then go
>>Address tso “submit *”
>> Else 
>>Sleep(10)
>>  Goto checkrc
>> End
>> 
>> Have to check the Rexx syntax but this will tell me I hope if the first job 
>> finished 
>> 
> Rexx has no GOTO.  Do not mistake SIGNAL for GOTO; it leads to perdition.
> I'll suggest instead (untested):
> 
> signal on NOVALUE
> do CheckRC = 1
>Address TSO “LISTBC” 
>If rc == 0 then  Address tso “submit *”
>   Else address SYSCALL sleep 10
> End CheckRC
> 
> Have to check the Rexx syntax
> 
> -- gil
> 
> --
> 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: Sharing data sets VSAM VB

2021-02-25 Thread Paul Gilmartin 
On Thu, 25 Feb 2021 09:02:38 -0500, Joseph Reichman wrote:

>I am running all of this from Rex building JCL searching files there are a 
>huge number of files so I break them up into different jobs 
>
>What I am going to try is do 
>Checkrc:
>Address TSO “LISTBC” 
>
>If rc == 0 then go
> Address tso “submit *”
>  Else 
> Sleep(10)
>   Goto checkrc
>End
>
>Have to check the Rexx syntax but this will tell me I hope if the first job 
>finished 
>
Rexx has no GOTO.  Do not mistake SIGNAL for GOTO; it leads to perdition.
I'll suggest instead (untested):

signal on NOVALUE
do CheckRC = 1
Address TSO “LISTBC” 
If rc == 0 then  Address tso “submit *”
   Else address SYSCALL sleep 10
End CheckRC

Have to check the Rexx syntax

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-25 Thread Joseph Reichman 
Work for the IRS don’t know if it’s available 

Will try to find out 

> On Feb 25, 2021, at 9:12 AM, David Spiegel  wrote:
> 
> Hi Joseph,
> You could also interrogate the job (provided that your employer has an SDSF 
> licence) via the SDSF API.
> 
> Regards,
> David
> 
>> On 2021-02-25 09:02, Joseph Reichman wrote:
>> I am running all of this from Rex building JCL searching files there are a 
>> huge number of files so I break them up into different jobs
>> 
>> What I am going to try is do
>> Checkrc:
>> Address TSO “LISTBC”
>> 
>> If rc == 0 then go
>>  Address tso “submit *”
>>   Else
>>  Sleep(10)
>>Goto checkrc
>> End
>> 
>> Have to check the Rexx syntax but this will tell me I hope if the first job 
>> finished
>> 
>> Thanks
>> 
>> 
>> 
 On Feb 25, 2021, at 8:51 AM, Paul Gilmartin 
 <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> On Wed, 24 Feb 2021 21:48:54 -0600, Joel C. Ewing wrote:
   .., most job schedulers have ways to inhibit conflicting jobs from
 running in parallel, like defining a single resource required ...
 
>>> A scheduler seems overkill.  DISP=MOD should suffice.
>>> 
>>> -- gil
>>> 
>>> --
>>> 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
>> .
> 
> --
> 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: Sharing data sets VSAM VB

2021-02-25 Thread David Spiegel 

Hi Joseph,
You could also interrogate the job (provided that your employer has an 
SDSF licence) via the SDSF API.


Regards,
David

On 2021-02-25 09:02, Joseph Reichman wrote:

I am running all of this from Rex building JCL searching files there are a huge 
number of files so I break them up into different jobs

What I am going to try is do
Checkrc:
Address TSO “LISTBC”

If rc == 0 then go
  Address tso “submit *”
   Else
  Sleep(10)
Goto checkrc
End

Have to check the Rexx syntax but this will tell me I hope if the first job 
finished

Thanks




On Feb 25, 2021, at 8:51 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

On Wed, 24 Feb 2021 21:48:54 -0600, Joel C. Ewing wrote:

   .., most job schedulers have ways to inhibit conflicting jobs from
running in parallel, like defining a single resource required ...


A scheduler seems overkill.  DISP=MOD should suffice.

-- gil

--
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
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-25 Thread Joseph Reichman 
I am running all of this from Rex building JCL searching files there are a huge 
number of files so I break them up into different jobs 

What I am going to try is do 
Checkrc:
Address TSO “LISTBC” 

If rc == 0 then go
 Address tso “submit *”
  Else 
 Sleep(10)
   Goto checkrc
End

Have to check the Rexx syntax but this will tell me I hope if the first job 
finished 

Thanks 



> On Feb 25, 2021, at 8:51 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 24 Feb 2021 21:48:54 -0600, Joel C. Ewing wrote:
>> 
>>   .., most job schedulers have ways to inhibit conflicting jobs from
>> running in parallel, like defining a single resource required ...
>> 
> A scheduler seems overkill.  DISP=MOD should suffice.
> 
> -- gil
> 
> --
> 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: Sharing data sets VSAM VB

2021-02-25 Thread Paul Gilmartin 
On Wed, 24 Feb 2021 21:48:54 -0600, Joel C. Ewing wrote:
>
>.., most job schedulers have ways to inhibit conflicting jobs from
>running in parallel, like defining a single resource required ...
>
A scheduler seems overkill.  DISP=MOD should suffice.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-24 Thread Joel C. Ewing 
SHR was primarily designed to allow a max of one writer and any number
of readers.   When you allow multiple writers, then there is no longer
an obvious definition of what is the desired/intended "correct" result
when two different processes want to update the same part of that data
set, so typically some solution unique to each application would have to
be implemented rather than a generic solution.

Depending on your other constraints, it might be simplest for all the
jobs to use their own unique data set and then use a sort/merge step to
combine the records in the desired order, if they must all be in a
single dataset -- or if the order is not significant, just concatenate
all the separate data sets together under a single DD to read as if they
were a single sequential data set for what ever application needs to
read the combined data.

Or if you have a job scheduler and these are production jobs that aren't
required to run concurrently but just have problems if that happens by
accident, most job schedulers have ways to inhibit conflicting jobs from
running in parallel, like defining a single resource required by each of
the conflicting jobs and which must be free before each job is
submitted.  That way you avoid having jobs tie up initiators waiting on
availability of a data set.

I'm sure there are other possibilities, depending on your constraints.
    Joel C Ewing

On 2/24/21 12:57 PM, Joseph Reichman wrote:
> You are correct in your assumption of what I am trying to do so what is the 
> point of share options
>
>
>
>> On Feb 24, 2021, at 12:55 PM, Joel C. Ewing  wrote:
>>
>> But if you are talking about having multiple jobs having the file open
>> for writing concurrently, pretty sure you are talking about either using
>> VSAM RLS or observing some fairly stringent rules that requires the
>> programs involved to manage file record integrity on their own and to
>> use a SHR option that allows multiple concurrent opens for write and
>> constantly refreshes buffers for each record processed.   It's not just
>> a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
>> multiple concurrent OPENs for write on a VSAM with the usual default SHR
>> options, only the 1st concurrent open for write will succeed.
>>
>> If the object is to be able to write randomly interspersed records from
>> multiple jobs running concurrently, another possibility that might be
>> explored is to use a UNIX file and have all the jobs append output to
>> the same unix "log" file.
>>
>> z/OS assumes you want file integrity and deterministic behavior and
>> enforces that on MVS data sets.
>> The Unix world assumes you want what you "ask" for and if you ask for
>> multiple processes to write to the same file concurrently in ways that
>> are non-deterministic, it assumes random ordering from concurrent writes
>> is acceptable.
>>
>> Joel C Ewing
>>
>>> On 2/24/21 11:11 AM, Massimo Biancucci wrote:
>>> Joseph,
>>>
>>> for sure.
>>>
>>> VSAM variable length is OK.
>>>
>>> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>>>
>>> Best regards.
>>> Max
>>>
>>> 
>>> Mail
>>> priva di virus. www.avast.com
>>> 
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>>> reichman...@gmail.com> ha scritto:
>>>
 Hi

 I have multiple jobs sharing the same the same output dataset

 It’s RECFM=VB

 Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
 can write to the same dataset
 Thanks

 ...

 -- 
 Joel C. Ewing

...

-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-24 Thread Paul Gilmartin 
On Wed, 24 Feb 2021 11:55:18 -0600, Joel C. Ewing wrote:
>...
>use a SHR option that allows multiple concurrent opens for write and
>constantly refreshes buffers for each record processed. ...
>
>If the object is to be able to write randomly interspersed records from
>multiple jobs running concurrently, another possibility that might be
>explored is to use a UNIX file and have all the jobs append output to
>the same unix "log" file.
>
Open the file with O_APPEND (C, REXX SYSCALL, JCL) or ">>" (Shell).
I have experienced poor performance appending to a UNIX file.
IBM support tells me that is a consequence of need to preserve
integrity.

>z/OS assumes you want file integrity and deterministic behavior and
>enforces that on MVS data sets.
>The Unix world assumes you want what you "ask" for and if you ask for
>multiple processes to write to the same file concurrently in ways that
>are non-deterministic, it assumes random ordering from concurrent writes
>is acceptable.
>
The randomness will be less for a single write() operation with a
a datum < kernel buffer size (131072?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-24 Thread Joseph Reichman 
You are correct in your assumption of what I am trying to do so what is the 
point of share options



> On Feb 24, 2021, at 12:55 PM, Joel C. Ewing  wrote:
> 
> But if you are talking about having multiple jobs having the file open
> for writing concurrently, pretty sure you are talking about either using
> VSAM RLS or observing some fairly stringent rules that requires the
> programs involved to manage file record integrity on their own and to
> use a SHR option that allows multiple concurrent opens for write and
> constantly refreshes buffers for each record processed.   It's not just
> a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
> multiple concurrent OPENs for write on a VSAM with the usual default SHR
> options, only the 1st concurrent open for write will succeed.
> 
> If the object is to be able to write randomly interspersed records from
> multiple jobs running concurrently, another possibility that might be
> explored is to use a UNIX file and have all the jobs append output to
> the same unix "log" file.
> 
> z/OS assumes you want file integrity and deterministic behavior and
> enforces that on MVS data sets.
> The Unix world assumes you want what you "ask" for and if you ask for
> multiple processes to write to the same file concurrently in ways that
> are non-deterministic, it assumes random ordering from concurrent writes
> is acceptable.
> 
> Joel C Ewing
> 
>> On 2/24/21 11:11 AM, Massimo Biancucci wrote:
>> Joseph,
>> 
>> for sure.
>> 
>> VSAM variable length is OK.
>> 
>> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>> 
>> Best regards.
>> Max
>> 
>> 
>> Mail
>> priva di virus. www.avast.com
>> 
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> 
>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>> reichman...@gmail.com> ha scritto:
>> 
>>> Hi
>>> 
>>> I have multiple jobs sharing the same the same output dataset
>>> 
>>> It’s RECFM=VB
>>> 
>>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>>> can write to the same dataset
>>> Thanks
>>> 
>>> --
>>> 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
> 
> 
> -- 
> Joel C. Ewing
> 
> --
> 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: Sharing data sets VSAM VB

2021-02-24 Thread Joel C. Ewing 
But if you are talking about having multiple jobs having the file open
for writing concurrently, pretty sure you are talking about either using
VSAM RLS or observing some fairly stringent rules that requires the
programs involved to manage file record integrity on their own and to
use a SHR option that allows multiple concurrent opens for write and
constantly refreshes buffers for each record processed.   It's not just
a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
multiple concurrent OPENs for write on a VSAM with the usual default SHR
options, only the 1st concurrent open for write will succeed.

If the object is to be able to write randomly interspersed records from
multiple jobs running concurrently, another possibility that might be
explored is to use a UNIX file and have all the jobs append output to
the same unix "log" file.

z/OS assumes you want file integrity and deterministic behavior and
enforces that on MVS data sets.
The Unix world assumes you want what you "ask" for and if you ask for
multiple processes to write to the same file concurrently in ways that
are non-deterministic, it assumes random ordering from concurrent writes
is acceptable.

    Joel C Ewing

On 2/24/21 11:11 AM, Massimo Biancucci wrote:
> Joseph,
>
> for sure.
>
> VSAM variable length is OK.
>
> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>
> Best regards.
> Max
>
> 
> Mail
> priva di virus. www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
> reichman...@gmail.com> ha scritto:
>
>> Hi
>>
>> I have multiple jobs sharing the same the same output dataset
>>
>> It’s RECFM=VB
>>
>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>> can write to the same dataset
>> Thanks
>>
>> --
>> 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


-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-24 Thread Joseph Reichman 
Thanks 

> On Feb 24, 2021, at 12:12 PM, Massimo Biancucci  wrote:
> 
> Joseph,
> 
> for sure.
> 
> VSAM variable length is OK.
> 
> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
> 
> Best regards.
> Max
> 
> 
> Mail
> priva di virus. www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>> reichman...@gmail.com> ha scritto:
>> 
>> Hi
>> 
>> I have multiple jobs sharing the same the same output dataset
>> 
>> It’s RECFM=VB
>> 
>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>> can write to the same dataset
>> Thanks
>> 
>> --
>> 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sharing data sets VSAM VB

2021-02-24 Thread Massimo Biancucci 
Joseph,

for sure.

VSAM variable length is OK.

When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.

Best regards.
Max


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
reichman...@gmail.com> ha scritto:

> Hi
>
> I have multiple jobs sharing the same the same output dataset
>
> It’s RECFM=VB
>
> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
> can write to the same dataset
> Thanks
>
> --
> 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

Sharing data sets VSAM VB

2021-02-24 Thread Joseph Reichman 
Hi

I have multiple jobs sharing the same the same output dataset 

It’s RECFM=VB

Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs can 
write to the same dataset 
Thanks 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN