🚀 go-pugleaf

--------------72A782B134CB0BD7E7AF84A7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry, I wouldn't have the foggiest idea.  I think that the
last time I worked on an IBM DOS system was in 1971.
Anyway, I doubt that the "IBM Guy" is anywhere near
being correct.  See:

 4.8.1.6 "COBOL/VSE Programming Guide" via IBM BookManager BookServer

which appears to have become applicable as long ago
as 1983.  Even DOS/VSE has emerged into the 20th
century (even if everybody else is in the 21st).

Kerry

Patrick Lee wrote:

> Kerry,
> Thanks for your detail explanation. But IBM guy told me the issue
> applies to COBOL/VSE even through it state in the COBOL manual that it
> only applies to DOS/COBOL. Is that true??
>
> PL.
> In article <3959284F.3C8D8027@msdw.com>,
>   Kerry Ellis <Kerry.Ellis@MSDW.com> wrote:
> > OS/VS Cobol was oblivious to the CICS environment.  The Inspect,
> > String and Unstring statements invoked routines that issued OS (not
> > CICS) Getmains.  Because OS/VS Cobol programs had to be term-
> > inated with an EXEC CICS RETURN, the Cobol runtime routines
> > were never given a chance to clean up; eventually, the CICS region
> > would run out of what used to be called "OSCOR" and incur an OS
> > abend such as S80A.  Nowadays, with Cobol II and the "new" LE
> > conforming compilers, all run time storage acquisition requests are
> > handled by environment specific library routines, so Inspect, String
> > and Unstring are given CICS DSA storage that is not different than
> > any other piece of transaction storage.  In addition, such programs
> > can be ended with a STOP RUN or an EXEC CICS RETURN;
> > both will go through normal program/run unit cleanup; however,
> > any task duration storage that is missed will be freed by task term-
> > ination.  (BTW, the restrictions against String, Unstring and Inspect
> > were dropped IIRC with the arrival of the Cobol II compiler which
> > was =E6ons ago.)
> >
> > Kerry
> >
> > "William M. Klein" wrote:
> >
> > > I believe that you are correct.  I tried to find this documented in
> the=
> >  COBOL
> > > manuals, but couldn't (easily).  HOWEVER, I can find the list of
> what "=
> > is"
> > > restricted under the current COBOL with CICS - and it doesn't
> include t=
> > hose
> > > verbs.  Check out:
> > >
> > > http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG204/4%
> 2e10%2=
> > e1%2e6
> > >
> > > --
> > > Bill Klein
> > >     wmklein <at> ix dot netcom dot com
> > > "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
> > > news:39587336.17BE2312@istar.ca...
> > > > I am forwarding this to comp.lang.cobol to verify my impression
> that =
> > VS
> > > > COBOL II, COBOL for MVS and VM and COBOL for MVS and VM have no
> > > > restrictions on the use of STRING, UNSTRING and INSPECT.  All of
> thes=
> > e
> > > > are 31 bit compilers.
> > > >
> > > > Clark Morris, CFM Technical Programming Services Inc.,
> cfmtech@istar.=
> > ca
> > > >
> > > > -------- Original Message --------
> > > > Subject: STRING, UNstring & INSPECT are not recommended
> > > > Date: Tue, 27 Jun 2000 09:14:00 GMT
> > > > From: Patrick Lee <patricklee@whbhk.com>
> > > > Organization: Deja.com - Before you buy.
> > > > Newsgroups: bit.listserv.cics-l
> > > >
> > > > Dear all,
> > > > According to IBM APAR II06138, we should not use STRING, UNSTRING,
> > > > INSPECT because they will eat up our 24bit Getvis area. Any
> > > > recommendation of alternatives for these 3 words????
> > > >
> > > > Thanks.
> > > >
> > > > Patrick.
> > > >
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Before you buy.
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--------------72A782B134CB0BD7E7AF84A7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Sorry, I wouldn't have the foggiest idea.&nbsp; I think that the
<br>last time I worked on an IBM DOS system was in 1971.
<br>Anyway, I doubt that the "IBM Guy" is anywhere near
<br>being correct.&nbsp; See:
<p>&nbsp;<a href="http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYVA001/4%2e8%2e1%2e6?ACTION=MATCHES&REQUEST=cics&TYPE=FUZZY&SHELF=IGYVS001&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT">4.8.1.6
"COBOL/VSE Programming Guide" via IBM BookManager BookServer</a>
<p>which appears to have become applicable as long ago
<br>as 1983.&nbsp; Even DOS/VSE has emerged into the 20th
<br>century (even if everybody else is in the 21st).
<p>Kerry
<p>Patrick Lee wrote:
<blockquote TYPE=CITE>Kerry,
<br>Thanks for your detail explanation. But IBM guy told me the issue
<br>applies to COBOL/VSE even through it state in the COBOL manual that
it
<br>only applies to DOS/COBOL. Is that true??
<p>PL.
<br>In article &lt;3959284F.3C8D8027@msdw.com>,
<br>&nbsp; Kerry Ellis &lt;Kerry.Ellis@MSDW.com> wrote:
<br>> OS/VS Cobol was oblivious to the CICS environment.&nbsp; The Inspect,
<br>> String and Unstring statements invoked routines that issued OS (not
<br>> CICS) Getmains.&nbsp; Because OS/VS Cobol programs had to be term-
<br>> inated with an EXEC CICS RETURN, the Cobol runtime routines
<br>> were never given a chance to clean up; eventually, the CICS region
<br>> would run out of what used to be called "OSCOR" and incur an OS
<br>> abend such as S80A.&nbsp; Nowadays, with Cobol II and the "new" LE
<br>> conforming compilers, all run time storage acquisition requests are
<br>> handled by environment specific library routines, so Inspect, String
<br>> and Unstring are given CICS DSA storage that is not different than
<br>> any other piece of transaction storage.&nbsp; In addition, such programs
<br>> can be ended with a STOP RUN or an EXEC CICS RETURN;
<br>> both will go through normal program/run unit cleanup; however,
<br>> any task duration storage that is missed will be freed by task term-
<br>> ination.&nbsp; (BTW, the restrictions against String, Unstring and
Inspect
<br>> were dropped IIRC with the arrival of the Cobol II compiler which
<br>> was =E6ons ago.)
<br>>
<br>> Kerry
<br>>
<br>> "William M. Klein" wrote:
<br>>
<br>> > I believe that you are correct.&nbsp; I tried to find this documented
in
<br>the=
<br>>&nbsp; COBOL
<br>> > manuals, but couldn't (easily).&nbsp; HOWEVER, I can find the list
of
<br>what "=
<br>> is"
<br>> > restricted under the current COBOL with CICS - and it doesn't
<br>include t=
<br>> hose
<br>> > verbs.&nbsp; Check out:
<br>> >
<br>> > <a href="http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG204/4%">http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG204/4%</a>
<br>2e10%2=
<br>> e1%2e6
<br>> >
<br>> > --
<br>> > Bill Klein
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; wmklein &lt;at> ix dot netcom dot com
<br>> > "Clark F. Morris, Jr." &lt;cfmtech@istar.ca> wrote in message
<br>> > <a href="news:39587336.17BE2312@istar.ca">news:39587336.17BE2312@istar.ca</a>...
<br>> > > I am forwarding this to comp.lang.cobol to verify my impression
<br>that =
<br>> VS
<br>> > > COBOL II, COBOL for MVS and VM and COBOL for MVS and VM have
no
<br>> > > restrictions on the use of STRING, UNSTRING and INSPECT.&nbsp;
All of
<br>thes=
<br>> e
<br>> > > are 31 bit compilers.
<br>> > >
<br>> > > Clark Morris, CFM Technical Programming Services Inc.,
<br>cfmtech@istar.=
<br>> ca
<br>> > >
<br>> > > -------- Original Message --------
<br>> > > Subject: STRING, UNstring &amp; INSPECT are not recommended
<br>> > > Date: Tue, 27 Jun 2000 09:14:00 GMT
<br>> > > From: Patrick Lee &lt;patricklee@whbhk.com>
<br>> > > Organization: Deja.com - Before you buy.
<br>> > > Newsgroups: bit.listserv.cics-l
<br>> > >
<br>> > > Dear all,
<br>> > > According to IBM APAR II06138, we should not use STRING, UNSTRING,
<br>> > > INSPECT because they will eat up our 24bit Getvis area. Any
<br>> > > recommendation of alternatives for these 3 words????
<br>> > >
<br>> > > Thanks.
<br>> > >
<br>> > > Patrick.
<br>> > >
<br>> > >
<br>> > > Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a>
<br>> > > Before you buy.
<br>>
<br>>
<p>Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a>
<br>Before you buy.</blockquote>
</html>

--------------72A782B134CB0BD7E7AF84A7--