Re: Cobol File Question

2017-12-03 Thread scott Ford
Tom,

Absolutely...I would like to have time to redesign

Scott

On Dec 1, 2017, 10:02 PM -0500, Savor, Thomas (Alpharetta) 
<thomas.sa...@fiserv.com>, wrote:
> In your call to the second program...that has the FD, he owns the file. If he 
> is always opening the file on every call and "should" close file on 
> exitthen I would be looking into where you can get out of 2nd program 
> without executing Close. Something like an error.
>
> Thanks,
>
> Tom Savor
> Software Developer, Sr
> FRMS-SCM
> Fiserv
> Office:  678-375-1307
> Mobile: 404-660-6898
> Fax:  678-375-3280
> www.fiserv.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of scott Ford
> Sent: Friday, December 01, 2017 5:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cobol File Question
>
> John,
>
> Yes exactly.., until I can convince an overly cautious manager we should 
> thread or multi-task.
>
> Thanks , John..I needed a sanity check
>
> On Dec 1, 2017, 4:55 PM -0500, John McKown <john.archie.mck...@gmail.com>, 
> wrote:
> > On Fri, Dec 1, 2017 at 3:42 PM, scott Ford <idfli...@gmail.com> wrote:
> >
> > > All:
> > >
> > > Sorry for the Cobol question but i have a question..
> > > I have s single thread STC calling a second Cobol program that
> > > second program opens files ( sysprint - defined as sequential ) and
> > > writes output. I need to close these files on termination of the STC.
> > > We have built an API ...my thought is to pass a variable indicating
> > > to close the files and set a return-code and return back and have
> > > the STC check it..
> > >
> >
> > ​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this
> > second program. The second program is doing an COBOL OPEN verb on an
> > FD whose SELECT is for DD SYSPRINT,? Am I correct so far? The second
> > program is not doing a COBOL CLOSE on the FD. When the second COBOL
> > program does a GOBACK, it returns to the first program. When the first
> > program terminates, the STC terminates. In this case, where some
> > program does an OPEN but there is no corresponding CLOSE, z/OS itself
> > will do a CLOSE on all still OPEN DDs when the __TCB__ under which
> > some program did the OPEN terminates. This is because OPEN chains DEBs
> > for all OPEN DDs on the TCB under which the OPEN was done. So if there
> > are any DEBs left on this chain, task termination does a CLOSE on them. 
> > This is not good practice, but it generally works.
> > VSAM data sets get an "abnormal close" set in the catalog for the DSN
> > which causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.
> >
> > Or am I totally off base as to what you are asking?
> >
> >
> >
> > >
> > > Am i thinking right ?
> > >
> > > --
> > >
> > > *IDMWORKS *
> > >
> > > Scott Ford
> > >
> > > z/OS Dev.
> > >
> >
> >
> > --
> > I have a theory that it's impossible to prove anything, but I can't
> > prove it.
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > 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: Cobol File Question

2017-12-01 Thread Savor, Thomas (Alpharetta)
In your call to the second program...that has the FD, he owns the file.  If he 
is always opening the file on every call and "should" close file on 
exitthen I would be looking into where you can get out of 2nd program 
without executing Close.  Something like an error.

Thanks,

Tom Savor
Software Developer, Sr
FRMS-SCM
Fiserv
Office:  678-375-1307
Mobile: 404-660-6898
Fax:  678-375-3280
www.fiserv.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Friday, December 01, 2017 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol File Question

John,

Yes exactly.., until I can convince an overly cautious manager we should thread 
or multi-task.

Thanks , John..I needed a sanity check

On Dec 1, 2017, 4:55 PM -0500, John McKown <john.archie.mck...@gmail.com>, 
wrote:
> On Fri, Dec 1, 2017 at 3:42 PM, scott Ford <idfli...@gmail.com> wrote:
>
> > All:
> >
> > Sorry for the Cobol question but i have a question..
> > I have s single thread STC calling a second Cobol program that 
> > second program opens files ( sysprint - defined as sequential ) and 
> > writes output. I need to close these files on termination of the STC.
> > We have built an API ...my thought is to pass a variable indicating 
> > to close the files and set a return-code and return back and have 
> > the STC check it..
> >
>
> ​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this 
> second program. The second program is doing an COBOL OPEN verb on an 
> FD whose SELECT is for DD SYSPRINT,? Am I correct so far? The second 
> program is not doing a COBOL CLOSE on the FD. When the second COBOL 
> program does a GOBACK, it returns to the first program. When the first 
> program terminates, the STC terminates. In this case, where some 
> program does an OPEN but there is no corresponding CLOSE, z/OS itself 
> will do a CLOSE on all still OPEN DDs when the __TCB__ under which 
> some program did the OPEN terminates. This is because OPEN chains DEBs 
> for all OPEN DDs on the TCB under which the OPEN was done. So if there 
> are any DEBs left on this chain, task termination does a CLOSE on them. This 
> is not good practice, but it generally works.
> VSAM data sets get an "abnormal close" set in the catalog for the DSN 
> which causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.
>
> Or am I totally off base as to what you are asking?
>
>
>
> >
> > Am i thinking right ?
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't 
> prove it.
>
> Maranatha! <><
> John McKown
>
> --
> 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: Cobol File Question

2017-12-01 Thread scott Ford
John,

Yes exactly.., until I can convince an overly cautious manager we should thread 
or multi-task.

Thanks , John..I needed a sanity check

On Dec 1, 2017, 4:55 PM -0500, John McKown , 
wrote:
> On Fri, Dec 1, 2017 at 3:42 PM, scott Ford  wrote:
>
> > All:
> >
> > Sorry for the Cobol question but i have a question..
> > I have s single thread STC calling a second Cobol program
> > that second program opens files ( sysprint - defined as sequential ) and
> > writes output. I need to close these files on termination of the STC.
> > We have built an API ...my thought is to pass a variable indicating to
> > close the files
> > and set a return-code and return back and have the STC check it..
> >
>
> ​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this second
> program. The second program is doing an COBOL OPEN verb on an FD whose
> SELECT is for DD SYSPRINT,? Am I correct so far? The second program is not
> doing a COBOL CLOSE on the FD. When the second COBOL program does a GOBACK,
> it returns to the first program. When the first program terminates, the STC
> terminates. In this case, where some program does an OPEN but there is no
> corresponding CLOSE, z/OS itself will do a CLOSE on all still OPEN DDs when
> the __TCB__ under which some program did the OPEN terminates. This is
> because OPEN chains DEBs for all OPEN DDs on the TCB under which the OPEN
> was done. So if there are any DEBs left on this chain, task termination
> does a CLOSE on them. This is not good practice, but it generally works.
> VSAM data sets get an "abnormal close" set in the catalog for the DSN which
> causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.
>
> Or am I totally off base as to what you are asking?
>
>
>
> >
> > Am i thinking right ?
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> 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: Cobol File Question

2017-12-01 Thread John McKown
On Fri, Dec 1, 2017 at 3:42 PM, scott Ford  wrote:

> All:
>
> Sorry for the Cobol question but i have a question..
> I have s single thread STC calling a second Cobol program
> that second program opens files ( sysprint - defined as sequential ) and
> writes output.  I need to close these files on termination of the STC.
> We have built an API ...my thought is to pass a variable indicating to
> close the files
> and set a return-code and return back and have the STC check it..
>

​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this second
program. The second program is doing an COBOL OPEN verb on an FD whose
SELECT is for DD SYSPRINT,?  Am I correct so far? The second program is not
doing a COBOL CLOSE on the FD. When the second COBOL program does a GOBACK,
it returns to the first program. When the first program terminates, the STC
terminates. In this case, where some program does an OPEN but there is no
corresponding CLOSE, z/OS itself will do a CLOSE on all still OPEN DDs when
the __TCB__ under which some program did the OPEN terminates. This is
because OPEN chains DEBs for all OPEN DDs on the TCB under which the OPEN
was done. So if there are any DEBs left on this chain, task termination
does a CLOSE on them. This is not good practice, but it generally works.
VSAM data sets get an "abnormal close" set in the catalog for the DSN which
causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.

Or am I totally off base as to what you are asking?



>
> Am i thinking right ?
>
> --
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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


Cobol File Question

2017-12-01 Thread scott Ford
All:

Sorry for the Cobol question but i have a question..
I have s single thread STC calling a second Cobol program
that second program opens files ( sysprint - defined as sequential ) and
writes output.  I need to close these files on termination of the STC.
We have built an API ...my thought is to pass a variable indicating to
close the files
and set a return-code and return back and have the STC check it..

Am i thinking right ?

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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