Re: LE question

[Brian Westerman]

This particular exit only looks at the commands issued (from consoles or jobs, 
etc.) so the overhead is pretty small.  I wanted to do a lot of optional work 
at the time though so it made more sense to code things so that they told me 
what to look at and I only looked at those commands (instead of looking at 
everything and only acting on some of them).

We still ship the exit though just in case a customer really feels strongly 
about getting the command before it even gets to anywhere else.

Brian

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

Re: LE question

[scott Ford]

Brian,

I would agree it must be a lot of overhead looking at everything and then
having the code make the decision on what to do.
Especially in a System exit.

Scott

On Thu, May 16, 2019 at 12:19 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> HI,
>
> ALL commands issued at a console or from a program or JCL are processed in
> the command exit, whether they are JES or MVS commands or just random text
> typed on the console.
>
> When I developed our console message processing facility, I originally set
> it up to run as a command exit and then changed it's location when I found
> that I was getting EVERY command and not just the ones I wanted to get. :)
>
> There is a lot of overhead in looking at everything, but when looking for
> individual items it's actually very efficient.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*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

Re: Saving in memory data in case of operator cancel was Re: LE question

[scott Ford]

Peter/Clark,

Since we are a ISV, we try to intervene ourselves. My issue was on how to
do it. I know LE  but I am faced with
we cant just convert to pure HLASM or even threaded C or C++ . So i have to
come up with an alternative solution
that works. We have been using Subpool 231 and it works fine except when an
Operator becomes impatient and
cancels the STC. I agree we use the PPT to enforce no cancel that would
prevent one issue. But since we capture
security (RACF, ACF2 and Top-Secret) events with exits and use SP231 as a
place to store them, we have to think about
data integrity and recovery. My thoughts thanks to Allan and the rest of
you guys is maybe a DataSpace might be what we want to do.

Scott

On Thu, May 16, 2019 at 7:39 AM Peter Relson  wrote:

> The choices are between saving the data yourself as you go, such as by
> some sort of checkpoint or other method, or saving the data yourself after
> the cancel (for which some sort of TERM=YES ESTAE-type recovery is
> necessary) or not allowing the CANCEL (whether by intercepting CANCEL or
> making the job non-cancelable).
>
> There are PPT attributes pertaining to whether or not a job can be
> canceled. I think that applies both to a job and to a started task.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*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

Re: Saving in memory data in case of operator cancel was Re: LE question

[Peter Relson]

The choices are between saving the data yourself as you go, such as by 
some sort of checkpoint or other method, or saving the data yourself after 
the cancel (for which some sort of TERM=YES ESTAE-type recovery is 
necessary) or not allowing the CANCEL (whether by intercepting CANCEL or 
making the job non-cancelable).

There are PPT attributes pertaining to whether or not a job can be 
canceled. I think that applies both to a job and to a started task.

Peter Relson
z/OS Core Technology Design


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

Re: LE question

[Brian Westerman]

HI,

ALL commands issued at a console or from a program or JCL are processed in the 
command exit, whether they are JES or MVS commands or just random text typed on 
the console.

When I developed our console message processing facility, I originally set it 
up to run as a command exit and then changed it's location when I found that I 
was getting EVERY command and not just the ones I wanted to get. :)

There is a lot of overhead in looking at everything, but when looking for 
individual items it's actually very efficient.

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

Saving in memory data in case of operator cancel was Re: LE question

[Clark Morris]

[Default] On 14 May 2019 11:23:01 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>All:
>
>I need to do some research on how job is cancelled via the Operator , Abend
>S222. I read through some of the Boston share doc of some time ago by Ed,
>Sam and Skip. Its great.
>I have a question in regard to something that was stated on the
>presentation.
>
>I have a job written in Cobol, this job has mission critical data storage
>in a table or array in program storage and that job has been cancelled by
>an Operator. I dont want to lose that data.

1. Did anyone ask the person who cancelled the job why it was done and
if so was there a  better alternative?

2.  If the data is that valuable checkpoint the program either with
z/OS supplied mechanisms or write your own.

Clark Morris
>I want to know how i should approach it. The other qualifier here is that
>this is Cobol v4.2 which i am stuck with.
>
>Would I have to write a non-LE assembler caller and somehow set and ESPIE
>or ESTAE and then somehow involve CALLRTM ?
>I have done a lot of digging and not sure recovery of this nature ( LE ) is
>mentioned. I understand Condition Handling can be called also but
>will it handle an Operator cancel ...I know there are products, thats not
>an option because of cost.
>
>Regards,

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

Re: LE question

[John McKown]

On Wed, May 15, 2019 at 10:14 AM Jesse 1 Robinson 
wrote:

> I was banging away at a reply for JES2 Exit 5 when I realized that most
> CANCEL commands are issued to MVS, not JES. Where would a 'C my-pet-task'
> be intercepted?
>


Perhaps?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae400/svc34.htm




>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that is a generic
> abend catcher and you execute it, passing it a parm of your program and it
> builds the ESTAEX cushion around your program.
>
> Alternatively, our SyzMPF/z product can intercept the cancel command and
> keep it from being done when you don't want it to be, so I'm sure that most
> if not all other automation products can do that same thing.
>
> You could also write a simple command exit which would intercept ALL
> cancel commands and do any kind of processing you want to it (including
> ignore it for certain jobs/tasks) and have that same exit allow some other
> command (like XANCLE instead of "CANCEL" or "C") to actually work for those
> jobs that are your favorites.
>
> Obviously our product makes this really easy, (it allows scripts with
> many, many variables to help decide if things should be allowed to happen
> or modify the commands and/or send email or text messages if/when commands
> are changed) and everyone should buy it from us, but it's really not that
> difficult to design and write your own for simple single use things like
> this.
>
> Brian
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

Re: LE question

[David Spiegel]

Hi Jesse,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae400/svc34.htm#svc34__cdemvs

Regards,
David

On 2019-05-15 11:13, Jesse 1 Robinson wrote:
> I was banging away at a reply for JES2 Exit 5 when I realized that most 
> CANCEL commands are issued to MVS, not JES. Where would a 'C my-pet-task' be 
> intercepted?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that is a generic abend 
> catcher and you execute it, passing it a parm of your program and it builds 
> the ESTAEX cushion around your program.
>
> Alternatively, our SyzMPF/z product can intercept the cancel command and keep 
> it from being done when you don't want it to be, so I'm sure that most if not 
> all other automation products can do that same thing.
>
> You could also write a simple command exit which would intercept ALL cancel 
> commands and do any kind of processing you want to it (including ignore it 
> for certain jobs/tasks) and have that same exit allow some other command 
> (like XANCLE instead of "CANCEL" or "C") to actually work for those jobs that 
> are your favorites.
>
> Obviously our product makes this really easy, (it allows scripts with many, 
> many variables to help decide if things should be allowed to happen or modify 
> the commands and/or send email or text messages if/when commands are changed) 
> and everyone should buy it from us, but it's really not that difficult to 
> design and write your own for simple single use things like this.
>
> Brian
>
>
> --
> 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: LE question

[Jesse 1 Robinson]

I was banging away at a reply for JES2 Exit 5 when I realized that most CANCEL 
commands are issued to MVS, not JES. Where would a 'C my-pet-task' be 
intercepted?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Tuesday, May 14, 2019 10:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: LE question

I think that one of the CBTtape files has a program that is a generic abend 
catcher and you execute it, passing it a parm of your program and it builds the 
ESTAEX cushion around your program.

Alternatively, our SyzMPF/z product can intercept the cancel command and keep 
it from being done when you don't want it to be, so I'm sure that most if not 
all other automation products can do that same thing.  

You could also write a simple command exit which would intercept ALL cancel 
commands and do any kind of processing you want to it (including ignore it for 
certain jobs/tasks) and have that same exit allow some other command (like 
XANCLE instead of "CANCEL" or "C") to actually work for those jobs that are 
your favorites.

Obviously our product makes this really easy, (it allows scripts with many, 
many variables to help decide if things should be allowed to happen or modify 
the commands and/or send email or text messages if/when commands are changed) 
and everyone should buy it from us, but it's really not that difficult to 
design and write your own for simple single use things like this.

Brian


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

Re: LE question

[Brian Westerman]

I think that one of the CBTtape files has a program that is a generic abend 
catcher and you execute it, passing it a parm of your program and it builds the 
ESTAEX cushion around your program.

Alternatively, our SyzMPF/z product can intercept the cancel command and keep 
it from being done when you don't want it to be, so I'm sure that most if not 
all other automation products can do that same thing.  

You could also write a simple command exit which would intercept ALL cancel 
commands and do any kind of processing you want to it (including ignore it for 
certain jobs/tasks) and have that same exit allow some other command (like 
XANCLE instead of "CANCEL" or "C") to actually work for those jobs that are 
your favorites.

Obviously our product makes this really easy, (it allows scripts with many, 
many variables to help decide if things should be allowed to happen or modify 
the commands and/or send email or text messages if/when commands are changed) 
and everyone should buy it from us, but it's really not that difficult to 
design and write your own for simple single use things like this.

Brian

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

Re: LE question

[Seymour J Metz]

You can get control in an ESTAE exit after a cancel, you can't do a retry. If 
your management isn't willing to rein in rogue operators than there is no good 
solution. At one point checkpoint/restart might have helped, but how many 
applications these days have only a single task?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Tuesday, May 14, 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE question

All:

I need to do some research on how job is cancelled via the Operator , Abend
S222. I read through some of the Boston share doc of some time ago by Ed,
Sam and Skip. Its great.
I have a question in regard to something that was stated on the
presentation.

I have a job written in Cobol, this job has mission critical data storage
in a table or array in program storage and that job has been cancelled by
an Operator. I dont want to lose that data.
I want to know how i should approach it. The other qualifier here is that
this is Cobol v4.2 which i am stuck with.

Would I have to write a non-LE assembler caller and somehow set and ESPIE
or ESTAE and then somehow involve CALLRTM ?
I have done a lot of digging and not sure recovery of this nature ( LE ) is
mentioned. I understand Condition Handling can be called also but
will it handle an Operator cancel ...I know there are products, thats not
an option because of cost.

Regards,

--



*IDMWORKS *

Scott Ford

z/OS Dev.




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



http://secure-web.cisco.com/1i6HehjnekxzPINpYjHo4xHxkhlaIaxo0mUQVzHZD8XuBxmIMjE4j9VFFiAegSf9cFHiQx-hLH7NgcDNxcDiHYrHWhF9-MB-8z8-hFkWaehTi6vaAKK-x2may5wKk6Wfur4Dz5mqUoIQVPyQww7JecRtP39WKljV5W9MFfhryIzn5CJxXMcZ6nY48U7x9IzqyZFH0fRM-FKUAFpeckQ3CGrPBonOSnKOD1N8Vhxq9izDhH49RnyEr9l1fbzsq4k-pl1sWQX4J3bop2xGgZivNCeZS-8GGy2L59xw0Noo8ruZuPT-SjRCouy6rqxApVBloGCoJDzLozSSHNnfytJO39tFDljE30Aet7iUDOaUaAEP1YwFc4dvxsSCEb0zsf_EGVY38usPCasOizskY7MPt2GJ4uYpo0_4Kb7ip8NKBMxjlXTUEfM15E8pz9_a9svwX/http%3A%2F%2Fwww.idmworks.com

scott.f...@idmworks.com

Blog: 
http://secure-web.cisco.com/1dg9HxTLnZxcpqR83IfIqactoHIAZEFJ4rPxwE3WwOu8SB_ySFT-YvKSVAaIQVyHbiJlHhGjBrIsgDpv9_PqYBPaKFWpzjBKa23bt1DKTK54n3Bg6_D6zdFbvzWG-tDX7UqVCHSz4kul2AgTjQR6mka3SIdtsl_eNr5GPQ_EuHzLDkhzsNPQzGQw_BsugseFtlDR53m6LA_tfQCeZjMvtR9UujlLL0ezxK-QxPEIkLsT2U9aH9smh32GHh8BKkiZbUZdsUJhUogFs8OyeFYusRfdRZ3uV47VM0tS6ig9oVgxEYPsi533JsRGEpOJLLUUt27WdqLcrHSBAQPjGBvgzgYh0NPO2msipV0WvrY5XTECpSAAXn27Q6HFiOwbxLeclu0ylqWTNaQPcGQcODH2nJddI8eIsA3kWWBZyPiAfAh-rzIpCn9JWxHLy2TX1U1sj/http%3A%2F%2Fwww.idmworks.com%2Fblog





*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

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

Re: LE question

[John McKown]

I might be going off on a weird tangent. But if this is a started task,
instead of a program running in a batch job. And if it can be run as a
single step STC (not sure if this is a requirement). And it resides in an
APF authorized library. Then I would "register" the program in the SCHEDnn
member with the PPT option of NOCANCEL. If anyone issues a CANCEL command,
it will be rejected. I think that a FORCE n,ARM will still work
however. But not many people, other than sysprogs, use that. I might ever
use the SYST option:

PPT PROGRAM(myprog) NOCANCEL SYST

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae200/ieae200540.htm


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

Re: LE question

[Elardus Engelbrecht]

scott Ford wrote:

>I need to do some research on how job is cancelled via the Operator , Abend 
>S222. I read through some of the Boston share doc of some time ago by Ed, Sam 
>and Skip. Its great.
>I have a job written in Cobol, this job has mission critical data storage in a 
>table or array in program storage and that job has been cancelled by an 
>Operator. I dont want to lose that data. 

Aw crap, crap CRAP! Just ensure that the lame operator ('tape ape') does not 
cancel your precious job(s). [1] 

Why, oh why, did he/she/it canceled that job in the first place? Huh? 
Did he/she/it smoked some 'Durban Poison' (dagga/marijuana)?

Stopping this cancelling fun will save you a lot of grey hairs and having you 
to invent innovative abend handling steps.


>I want to know how i should approach it. The other qualifier here is that this 
>is Cobol v4.2 which i am stuck with.

There is no way to recover the data, unless you have a backup and the COBOL 
program can be rerun without any extra steps.

Ouch, your scenario is a real PITA! Sorry for not giving you a real solution on 
how to handle that S222 abend.

Groete / Greetings
Elardus Engelbrecht

[1] - These ops also just reply on a console WTOR with whatever they want... 
Gr...

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

Re: LE question

[Binyamin Dissen]

On Tue, 14 May 2019 14:22:37 -0400 scott Ford  wrote:

:>I need to do some research on how job is cancelled via the Operator , Abend
:>S222. I read through some of the Boston share doc of some time ago by Ed,
:>Sam and Skip. Its great.
:>I have a question in regard to something that was stated on the
:>presentation.
:>
:>I have a job written in Cobol, this job has mission critical data storage
:>in a table or array in program storage and that job has been cancelled by
:>an Operator. I dont want to lose that data.

Well, the first step would to not allow the job to be canceled. One would
think that automation products would be able to do that.

And instructions to the operator. Why would he be willy-nilly canceling jobs?

:>I want to know how i should approach it. The other qualifier here is that
:>this is Cobol v4.2 which i am stuck with.

I would approach this procedurally.

:>Would I have to write a non-LE assembler caller and somehow set and ESPIE
:>or ESTAE and then somehow involve CALLRTM ?
:>I have done a lot of digging and not sure recovery of this nature ( LE ) is
:>mentioned. I understand Condition Handling can be called also but
:>will it handle an Operator cancel ...I know there are products, thats not
:>an option because of cost.

What about if the job abends from its own failures?

This sounds like what checkpoint/restart was made for. 

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: LE question

[Allan Staller]

Good luck!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
scott Ford
Sent: Tuesday, May 14, 2019 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

Alan,

I found some more info, we have a ECVT customer table entry. This sounds like 
what I want.

Scott

On Tue, May 14, 2019 at 2:55 PM scott Ford  wrote:

> Alan,
>
> A big thanks ..A Common Dataspace is good , i will have to find how to 
> anchor ..homework.
>
> Regards,
> Scott
>
> On Tue, May 14, 2019 at 2:45 PM Allan Staller 
> wrote:
>
>> That is why I specified a COMMON data space (as opposed to a data 
>> space), and the init/term routines.
>> A "data space" has no persistence beyond the creating task. A "common 
>> dataspace" is anchored somewhere in the operating system.
>> I will leave the details to your perusal of the FM's.
>> Recommended reading:
>> SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level 
>> Languages
>> SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide
>>
>> For the pendants on the list, please forgive me I have used incorrect 
>> terminology.
>> Additional responses interspersed below.
>>
>> HTH,
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of scott Ford
>> Sent: Tuesday, May 14, 2019 1:35 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: LE question
>>
>> Alan,
>>
>> Yes that was my thinking. What about persistence ?
>> --> "common dataspace" vs. dataspace.
>> My question is there a dataspace that can be up without an owning 
>> running TCB ?
>> --> YES
>> Even it is require, if memory serves me another program if they need 
>> to access the dataspace can query for the ALET ?
>> --> See recommended reading
>> Can someone tell me if i am correct ?
>>
>> Scott
>>
>> On Tue, May 14, 2019 at 2:28 PM Allan Staller 
>> wrote:
>>
>> > Common Data Space? This is kind of what data spaces were invented for.
>> > An init routine  to run more or less  @ IPL time to create, anchor 
>> > and load the data space.
>> > Cobol to access/update the data via the dataspace Optional routine 
>> > to save the dataspace @ shutdown.
>> >
>> > HTH,
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On 
>> > Behalf Of scott Ford
>> > Sent: Tuesday, May 14, 2019 1:23 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: LE question
>> >
>> > All:
>> >
>> > I need to do some research on how job is cancelled via the Operator 
>> > , Abend S222. I read through some of the Boston share doc of some 
>> > time ago by Ed, Sam and Skip. Its great.
>> > I have a question in regard to something that was stated on the 
>> > presentation.
>> >
>> > I have a job written in Cobol, this job has mission critical data 
>> > storage in a table or array in program storage and that job has 
>> > been cancelled by an Operator. I dont want to lose that data.
>> > I want to know how i should approach it. The other qualifier here 
>> > is that this is Cobol v4.2 which i am stuck with.
>> >
>> > Would I have to write a non-LE assembler caller and somehow set and 
>> > ESPIE or ESTAE and then somehow involve CALLRTM ?
>> > I have done a lot of digging and not sure recovery of this nature ( 
>> > LE
>> > ) is mentioned. I understand Condition Handling can be called also 
>> > but will it handle an Operator cancel ...I know there are products, 
>> > thats not an option because of cost.
>> >
>> > Regards,
>> >
>> > --
>> >
>> >
>> >
>> > *IDMWORKS *
>> >
>> > Scott Ford
>> >
>> > z/OS Dev.
>> >
>> >
>> >
>> >
>> > “By elevating a friend or Collegue you elevate yourself, by 
>> > demeaning a friend or collegue you demean yourself”
>> >
>> >
>> >
>> >
>> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.co
>> > m
>> > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d
>> > 6d8
>> > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752
>> > 619 
>> > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dres
>> > erv
>> > ed=0
>> >
>> > scott.f.

Re: LE question

[scott Ford]

Alan,

I found some more info, we have a ECVT customer table entry. This sounds
like what I want.

Scott

On Tue, May 14, 2019 at 2:55 PM scott Ford  wrote:

> Alan,
>
> A big thanks ..A Common Dataspace is good , i will have to find how to
> anchor ..homework.
>
> Regards,
> Scott
>
> On Tue, May 14, 2019 at 2:45 PM Allan Staller 
> wrote:
>
>> That is why I specified a COMMON data space (as opposed to a data space),
>> and the init/term routines.
>> A "data space" has no persistence beyond the creating task. A "common
>> dataspace" is anchored somewhere in the operating system.
>> I will leave the details to your perusal of the FM's.
>> Recommended reading:
>> SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level
>> Languages
>> SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide
>>
>> For the pendants on the list, please forgive me I have used incorrect
>> terminology.
>> Additional responses interspersed below.
>>
>> HTH,
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of scott Ford
>> Sent: Tuesday, May 14, 2019 1:35 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: LE question
>>
>> Alan,
>>
>> Yes that was my thinking. What about persistence ?
>> --> "common dataspace" vs. dataspace.
>> My question is there a dataspace that can be up without an owning running
>> TCB ?
>> --> YES
>> Even it is require, if memory serves me another program if they need to
>> access the dataspace can query for the ALET ?
>> --> See recommended reading
>> Can someone tell me if i am correct ?
>>
>> Scott
>>
>> On Tue, May 14, 2019 at 2:28 PM Allan Staller 
>> wrote:
>>
>> > Common Data Space? This is kind of what data spaces were invented for.
>> > An init routine  to run more or less  @ IPL time to create, anchor and
>> > load the data space.
>> > Cobol to access/update the data via the dataspace Optional routine to
>> > save the dataspace @ shutdown.
>> >
>> > HTH,
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> > Behalf Of scott Ford
>> > Sent: Tuesday, May 14, 2019 1:23 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: LE question
>> >
>> > All:
>> >
>> > I need to do some research on how job is cancelled via the Operator ,
>> > Abend S222. I read through some of the Boston share doc of some time
>> > ago by Ed, Sam and Skip. Its great.
>> > I have a question in regard to something that was stated on the
>> > presentation.
>> >
>> > I have a job written in Cobol, this job has mission critical data
>> > storage in a table or array in program storage and that job has been
>> > cancelled by an Operator. I dont want to lose that data.
>> > I want to know how i should approach it. The other qualifier here is
>> > that this is Cobol v4.2 which i am stuck with.
>> >
>> > Would I have to write a non-LE assembler caller and somehow set and
>> > ESPIE or ESTAE and then somehow involve CALLRTM ?
>> > I have done a lot of digging and not sure recovery of this nature ( LE
>> > ) is mentioned. I understand Condition Handling can be called also but
>> > will it handle an Operator cancel ...I know there are products, thats
>> > not an option because of cost.
>> >
>> > Regards,
>> >
>> > --
>> >
>> >
>> >
>> > *IDMWORKS *
>> >
>> > Scott Ford
>> >
>> > z/OS Dev.
>> >
>> >
>> >
>> >
>> > “By elevating a friend or Collegue you elevate yourself, by demeaning
>> > a friend or collegue you demean yourself”
>> >
>> >
>> >
>> >
>> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com
>> > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8
>> > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619
>> > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv
>> > ed=0
>> >
>> > scott.f...@idmworks.com
>> >
>> > Blog:
>> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2
>> > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769
>> > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7

Re: LE question

[scott Ford]

Alan,

A big thanks ..A Common Dataspace is good , i will have to find how to
anchor ..homework.

Regards,
Scott

On Tue, May 14, 2019 at 2:45 PM Allan Staller  wrote:

> That is why I specified a COMMON data space (as opposed to a data space),
> and the init/term routines.
> A "data space" has no persistence beyond the creating task. A "common
> dataspace" is anchored somewhere in the operating system.
> I will leave the details to your perusal of the FM's.
> Recommended reading:
> SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level
> Languages
> SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide
>
> For the pendants on the list, please forgive me I have used incorrect
> terminology.
> Additional responses interspersed below.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of scott Ford
> Sent: Tuesday, May 14, 2019 1:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> Alan,
>
> Yes that was my thinking. What about persistence ?
> --> "common dataspace" vs. dataspace.
> My question is there a dataspace that can be up without an owning running
> TCB ?
> --> YES
> Even it is require, if memory serves me another program if they need to
> access the dataspace can query for the ALET ?
> --> See recommended reading
> Can someone tell me if i am correct ?
>
> Scott
>
> On Tue, May 14, 2019 at 2:28 PM Allan Staller 
> wrote:
>
> > Common Data Space? This is kind of what data spaces were invented for.
> > An init routine  to run more or less  @ IPL time to create, anchor and
> > load the data space.
> > Cobol to access/update the data via the dataspace Optional routine to
> > save the dataspace @ shutdown.
> >
> > HTH,
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of scott Ford
> > Sent: Tuesday, May 14, 2019 1:23 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: LE question
> >
> > All:
> >
> > I need to do some research on how job is cancelled via the Operator ,
> > Abend S222. I read through some of the Boston share doc of some time
> > ago by Ed, Sam and Skip. Its great.
> > I have a question in regard to something that was stated on the
> > presentation.
> >
> > I have a job written in Cobol, this job has mission critical data
> > storage in a table or array in program storage and that job has been
> > cancelled by an Operator. I dont want to lose that data.
> > I want to know how i should approach it. The other qualifier here is
> > that this is Cobol v4.2 which i am stuck with.
> >
> > Would I have to write a non-LE assembler caller and somehow set and
> > ESPIE or ESTAE and then somehow involve CALLRTM ?
> > I have done a lot of digging and not sure recovery of this nature ( LE
> > ) is mentioned. I understand Condition Handling can be called also but
> > will it handle an Operator cancel ...I know there are products, thats
> > not an option because of cost.
> >
> > Regards,
> >
> > --
> >
> >
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
> >
> >
> >
> > “By elevating a friend or Collegue you elevate yourself, by demeaning
> > a friend or collegue you demean yourself”
> >
> >
> >
> >
> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com
> > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8
> > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619
> > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv
> > ed=0
> >
> > scott.f...@idmworks.com
> >
> > Blog:
> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2
> > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769
> > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455768
> > 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw%3D
> > reserved=0
> >
> >
> >
> >
> >
> > *The information contained in this email message and any attachment
> > may be privileged, confidential, proprietary or otherwise protected
> > from disclosure. If the

Re: LE question

[Allan Staller]

That is why I specified a COMMON data space (as opposed to a data space), and 
the init/term routines.
A "data space" has no persistence beyond the creating task. A "common 
dataspace" is anchored somewhere in the operating system.
I will leave the details to your perusal of the FM's.
Recommended reading:
SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level Languages 
SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide 

For the pendants on the list, please forgive me I have used incorrect 
terminology. 
Additional responses interspersed below.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
scott Ford
Sent: Tuesday, May 14, 2019 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

Alan,

Yes that was my thinking. What about persistence ?
--> "common dataspace" vs. dataspace.
My question is there a dataspace that can be up without an owning running TCB ?
--> YES
Even it is require, if memory serves me another program if they need to access 
the dataspace can query for the ALET ?
--> See recommended reading 
Can someone tell me if i am correct ?

Scott

On Tue, May 14, 2019 at 2:28 PM Allan Staller  wrote:

> Common Data Space? This is kind of what data spaces were invented for.
> An init routine  to run more or less  @ IPL time to create, anchor and 
> load the data space.
> Cobol to access/update the data via the dataspace Optional routine to 
> save the dataspace @ shutdown.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of scott Ford
> Sent: Tuesday, May 14, 2019 1:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LE question
>
> All:
>
> I need to do some research on how job is cancelled via the Operator , 
> Abend S222. I read through some of the Boston share doc of some time 
> ago by Ed, Sam and Skip. Its great.
> I have a question in regard to something that was stated on the 
> presentation.
>
> I have a job written in Cobol, this job has mission critical data 
> storage in a table or array in program storage and that job has been 
> cancelled by an Operator. I dont want to lose that data.
> I want to know how i should approach it. The other qualifier here is 
> that this is Cobol v4.2 which i am stuck with.
>
> Would I have to write a non-LE assembler caller and somehow set and 
> ESPIE or ESTAE and then somehow involve CALLRTM ?
> I have done a lot of digging and not sure recovery of this nature ( LE 
> ) is mentioned. I understand Condition Handling can be called also but 
> will it handle an Operator cancel ...I know there are products, thats 
> not an option because of cost.
>
> Regards,
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning 
> a friend or collegue you demean yourself”
>
>
>
>
> https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com
> mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8
> 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619
> sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv
> ed=0
>
> scott.f...@idmworks.com
>
> Blog:
> https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2
> Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769
> a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455768
> 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw%3D
> reserved=0
>
>
>
>
>
> *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
> ::DISCLAIMER::
>
> --
> --
> --
> 
> The contents of this e-mail and any attachment(s) are confidentia

Re: LE question

[scott Ford]

Alan,

Yes that was my thinking. What about persistence ?
My question is there a dataspace that can be up without an owning running
TCB ?
Even it is require, if memory serves me another program if they need to
access the dataspace can query for the ALET ?
Can someone tell me if i am correct ?

Scott

On Tue, May 14, 2019 at 2:28 PM Allan Staller  wrote:

> Common Data Space? This is kind of what data spaces were invented for.
> An init routine  to run more or less  @ IPL time to create, anchor and
> load the data space.
> Cobol to access/update the data via the dataspace
> Optional routine to save the dataspace @ shutdown.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of scott Ford
> Sent: Tuesday, May 14, 2019 1:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LE question
>
> All:
>
> I need to do some research on how job is cancelled via the Operator ,
> Abend S222. I read through some of the Boston share doc of some time ago by
> Ed, Sam and Skip. Its great.
> I have a question in regard to something that was stated on the
> presentation.
>
> I have a job written in Cobol, this job has mission critical data storage
> in a table or array in program storage and that job has been cancelled by
> an Operator. I dont want to lose that data.
> I want to know how i should approach it. The other qualifier here is that
> this is Cobol v4.2 which i am stuck with.
>
> Would I have to write a non-LE assembler caller and somehow set and ESPIE
> or ESTAE and then somehow involve CALLRTM ?
> I have done a lot of digging and not sure recovery of this nature ( LE )
> is mentioned. I understand Condition Handling can be called also but will
> it handle an Operator cancel ...I know there are products, thats not an
> option because of cost.
>
> Regards,
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
>
> https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.comdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=huczJhFn5eteBZJp2I%2BRNbzzK2MzZVNXbaNkXPFUGXc%3Dreserved=0
>
> scott.f...@idmworks.com
>
> Blog:
> https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=V1Ah%2FVAlb9m%2FftOG%2FD8TgXV8DYeSJRNUFUADHBVgjWo%3Dreserved=0
>
>
>
>
>
> *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
> ::DISCLAIMER::
>
> --
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message witho

Re: LE question

[Allan Staller]

Common Data Space? This is kind of what data spaces were invented for.
An init routine  to run more or less  @ IPL time to create, anchor and load the 
data space.
Cobol to access/update the data via the dataspace
Optional routine to save the dataspace @ shutdown.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
scott Ford
Sent: Tuesday, May 14, 2019 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE question

All:

I need to do some research on how job is cancelled via the Operator , Abend 
S222. I read through some of the Boston share doc of some time ago by Ed, Sam 
and Skip. Its great.
I have a question in regard to something that was stated on the presentation.

I have a job written in Cobol, this job has mission critical data storage in a 
table or array in program storage and that job has been cancelled by an 
Operator. I dont want to lose that data.
I want to know how i should approach it. The other qualifier here is that this 
is Cobol v4.2 which i am stuck with.

Would I have to write a non-LE assembler caller and somehow set and ESPIE or 
ESTAE and then somehow involve CALLRTM ?
I have done a lot of digging and not sure recovery of this nature ( LE ) is 
mentioned. I understand Condition Handling can be called also but will it 
handle an Operator cancel ...I know there are products, thats not an option 
because of cost.

Regards,

--



*IDMWORKS *

Scott Ford

z/OS Dev.




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



https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.comdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=huczJhFn5eteBZJp2I%2BRNbzzK2MzZVNXbaNkXPFUGXc%3Dreserved=0

scott.f...@idmworks.com

Blog: 
https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=V1Ah%2FVAlb9m%2FftOG%2FD8TgXV8DYeSJRNUFUADHBVgjWo%3Dreserved=0





*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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

LE question

[scott Ford]

All:

I need to do some research on how job is cancelled via the Operator , Abend
S222. I read through some of the Boston share doc of some time ago by Ed,
Sam and Skip. Its great.
I have a question in regard to something that was stated on the
presentation.

I have a job written in Cobol, this job has mission critical data storage
in a table or array in program storage and that job has been cancelled by
an Operator. I dont want to lose that data.
I want to know how i should approach it. The other qualifier here is that
this is Cobol v4.2 which i am stuck with.

Would I have to write a non-LE assembler caller and somehow set and ESPIE
or ESTAE and then somehow involve CALLRTM ?
I have done a lot of digging and not sure recovery of this nature ( LE ) is
mentioned. I understand Condition Handling can be called also but
will it handle an Operator cancel ...I know there are products, thats not
an option because of cost.

Regards,

-- 



*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

Re: COBOL/LE question

[Paul Gilmartin]

On Mon, 13 Feb 2017 17:50:22 -0600, Dale R. Smith wrote:
>
>http://www.computerworld.com/article/3163192/data-center/just-because-it-fails-doesnt-mean-its-a-failure.html
> 
I had one of those, many years ago.  We were trying to convert our programmers
from HLASM to an ISV cross-assembler.  One of our programmers resisted.  He
had a program that assembled with RC=0 on HLASM; RC=4 on the cross-assembler.
I reviewed the code and spotted an unresolvable expression that HLASM overlooked
and the cross-assembler reported properly.  Went to SR on HLASM.  Got APAR.
Now both get RC=4.  The programmer, fastidious about RC<>0, grudgingly changed
his code.

Software, this time.

-- gil

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

Re: COBOL/LE question

[Dale R. Smith]

On Mon, 13 Feb 2017 20:57:56 +, Pommier, Rex  
wrote:

>All,
>
>Just to circle back and close the issue, I was "barking up the wrong tree" 
>with the IGZ0268W message.  Turns out the driver program that was calling the 
>OS/VS COBOL program had a logic error in it that was calling the wrong program 
>with the wrong parameters.  I don't know why/how it was working on the 1.13 
>system, but a long time ago, the COBOL program that was initiating the abend 
>was replaced by another OS/VS COBOL program.  Unfortunately the developer who 
>wrote the new COBOL program missed one of the calls in the driving ASM 
>program.  Somehow it has chugged along all these years (obviously the COBOL 
>program being called at this one point didn't do anything important) until the 
>OS upgrade.  IBM must have closed a hole in LE maintenance between 1.13 and 
>2.2 and so this logic error that was sliding past now bit us.  Modifying the 
>ASM source to remove the broken call fixed the problem.  Since there are other 
>OS/VS COBOL programs being called by this same ASM driver that are working 
>fine, it wasn't the warning message after all.
>
>Thanks again for all your suggestions and help.
>
>Rex

http://www.computerworld.com/article/3163192/data-center/just-because-it-fails-doesnt-mean-its-a-failure.html

-- 
Dale R. Smith

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

Re: COBOL/LE question

[Pommier, Rex]

All,

Just to circle back and close the issue, I was "barking up the wrong tree" with 
the IGZ0268W message.  Turns out the driver program that was calling the OS/VS 
COBOL program had a logic error in it that was calling the wrong program with 
the wrong parameters.  I don't know why/how it was working on the 1.13 system, 
but a long time ago, the COBOL program that was initiating the abend was 
replaced by another OS/VS COBOL program.  Unfortunately the developer who wrote 
the new COBOL program missed one of the calls in the driving ASM program.  
Somehow it has chugged along all these years (obviously the COBOL program being 
called at this one point didn't do anything important) until the OS upgrade.  
IBM must have closed a hole in LE maintenance between 1.13 and 2.2 and so this 
logic error that was sliding past now bit us.  Modifying the ASM source to 
remove the broken call fixed the problem.  Since there are other OS/VS COBOL 
programs being called by this same ASM driver that are working fine, it wasn't 
the warning message after all.

Thanks again for all your suggestions and help.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Wednesday, February 01, 2017 4:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

We're starting down that path.  Management doesn't want to have to recompile 
things but I'm thinking we may need to do so just to see if that's the problem.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, February 01, 2017 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

I have a simple question do you happen to have a the source modules that if you 
attempted to reassemble them and recompile them to see if that's the problem

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
> 
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to suppress the message.  Normally that is OK but we have an ancient load 
> module written partially in OS/VS COBOL and partially in assembler that has a 
> home-grown ESTAE routine attached to it.  This program has consistently 
> failed spectacularly while testing it under 2.2.  Here's the sequence of 
> events.
> 
> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED
> <<<< 4 normal messages issued at start of run
> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
> 
> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001 
> 
> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED   
> 
> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)  
> <<<< first abend message
> 
> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> 
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
>  AT THE TIME OF INTERRUPT  
>  PSW 0008 804340DA 
>  GPR 0-3 0043D9A8 0043D668 0043D668 00433038   
>  GPR 4-7 0043D38C 0043D698 00433038 0043D658   
>  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0   
>  GPR C-F 0042AC30 0043D490 804340DA 966F4958   
> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407  
>  WHILE RUNNING PROGRAM UNKNOWN 
>  AT THE TIME OF INTERRUPT  
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to sup

Re: COBOL/LE question

[scott Ford]

Rex,

I sure would re-compile the Cobol programs. I have ran into issues but it
was going backward. It was in regard to callable LE functions and what was
supported...

Scott

On Thu, Feb 2, 2017 at 12:12 PM, Bill Woodger 
wrote:

> The IGZ0268W is a warning message (no kidding). If your are using up to
> Enterprise COBOL V4.2 (which you are), it is just a warning that some time
> in the future (going to V5+, or perhaps with some future LE) you *will*
> have a problem. If you are using V5+ (which you are not) it is a problem
> right now.
>
> You have a different case from it just being COBOL. Your combined
> COBOL/ASM was previously running non-destructively with LE. And now it
> doesn't.
>
> First shot would be to recompile one COBOL program that uses the Asm, and
> see if you then get cooperation. If not, someone has to visit with the Asm.
>
> If you are simply not allowed to recompile (cast-iron policy), then just
> pack up and go home early. It is highly unlikely that any simple magic
> exists to fix it in such a way that you need cease to wonder "OK, but what
> the heck else could be going on while it 'apparently works (RC0)'.
>
> --
> 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/LE question

[Bill Woodger]

The IGZ0268W is a warning message (no kidding). If your are using up to 
Enterprise COBOL V4.2 (which you are), it is just a warning that some time in 
the future (going to V5+, or perhaps with some future LE) you *will* have a 
problem. If you are using V5+ (which you are not) it is a problem right now.

You have a different case from it just being COBOL. Your combined COBOL/ASM was 
previously running non-destructively with LE. And now it doesn't.

First shot would be to recompile one COBOL program that uses the Asm, and see 
if you then get cooperation. If not, someone has to visit with the Asm.

If you are simply not allowed to recompile (cast-iron policy), then just pack 
up and go home early. It is highly unlikely that any simple magic exists to fix 
it in such a way that you need cease to wonder "OK, but what the heck else 
could be going on while it 'apparently works (RC0)'.

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

Re: COBOL/LE question

[Pommier, Rex]

No I don't.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Thursday, February 02, 2017 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

You would not happen to have z/XDC to debug this mess?

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Thursday, February 2, 2017 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

Hi Kolusu,

Thanks for the idea.  Unfortunately it made no difference.  The initial driver 
program being executed here is assembler which is calling COBOL programs.  
Looks like it is time to dig into an estae routine.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Wednesday, February 01, 2017 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

Rex,

I forgot to mention that DO NOT SET  RTEREUS(ON) as default.  Just set it for 
the particular job you are having problem with.

Something like this

//STEP0100  EXEC PGM=yourpgm,PARM='RTEREUS(ON)/any le parms if u have'

Here are some old topics on migration

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/DFSpeCSKUog 

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/_QnqYPU3eIk


Thanks,
Kolusu



From:   "Pommier, Rex" <rpomm...@sfgmembers.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   02/01/2017 03:41 PM
Subject:    COBOL/LE question
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Hello all,

We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into an 
issue with our COBOL and LE environment.  We are running COBOL 4.2.
Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
introduced the warning message "IGZ0268W An invocation was made of OS/VS COBOL 
program XXX." along with providing a usermod that can be installed to 
suppress the message.  Normally that is OK but we have an ancient load module 
written partially in OS/VS COBOL and partially in assembler that has a 
home-grown ESTAE routine attached to it.  This program has consistently failed 
spectacularly while testing it under 2.2. 
Here's the sequence of events.

13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   <<<< 
4 normal messages issued at start of run
13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001
13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED
13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 
(LE)  <<<< first abend message

$HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 
+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. 
+CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406
  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 0043D9A8 0043D668 0043D668 00433038 
  GPR 4-7 0043D38C 0043D698 00433038 0043D658 
  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 
  GPR C-F 0042AC30 0043D490 804340DA 966F4958 
+CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407
  WHILE RUNNING PROGRAM UNKNOWN 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 00441DE0 00441AA0 00441AA0 00433038 
  GPR 4-7 0044187C 00441AD0 00433038 00441A90 
  GPR 8-B 0042CED0 0008 0045D050 9687F3B0 
  GPR C-F 0042AC30 004418C8 804340DA 966F4958 
  FLT 0-2 49310F59C000  4E00030869B8 
  FLT 4-6 4E025368  

IEA995I SYMPTOM DUMP OUTPUT  417
  USER COMPLETION CODE=4087 REASON CODE=
 TIME=13.06.50  SEQ=00312  CPU=  ASID=0045 
 PSW AT TIME OF ERROR  078D1000   966A5806  ILC 2  INTC 0D 
   ACTIVE LOAD MODULE   ADDRESS=1660D410  OFFSET=000983F6 
   NAME=CEEPLPKA 
   DATA AT PSW  166A5800 - 00181610  0A0DA7F4  001C1811 
   GR 0: 8400   1: 84000FF7 
  2:    3: 00433038 
  4: 166E8398   5: 166E8A34 
  6: 00429358   7: 166A57CA 
  8: 8000   9: 00443EC6 
  A: 0001   B: 966A5728 
  C: 0042AC30   D: 00441EC8 
  E: 8043404E   F:  
 END OF SYMPTOM DUMP 
 

I'm not asking anybody to chase the dumps for me or anything like that, just 
wondering if anybody has had issues like this while migrating to 2.2. 
 I added a STEPLIB to the job step to point to the 1.13 SCEERUN and
SCEERUN2 libraries and the program runs fine.  I've tried it with and without 
the USERMOD designed to suppress the warning message about OS/VS COBOL to no 
avail.  To make it 

Re: COBOL/LE question

[Steve Beaver]

You would not happen to have z/XDC to debug this mess?

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Thursday, February 2, 2017 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

Hi Kolusu,

Thanks for the idea.  Unfortunately it made no difference.  The initial
driver program being executed here is assembler which is calling COBOL
programs.  Looks like it is time to dig into an estae routine.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sri h Kolusu
Sent: Wednesday, February 01, 2017 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

Rex,

I forgot to mention that DO NOT SET  RTEREUS(ON) as default.  Just set it
for the particular job you are having problem with.

Something like this

//STEP0100  EXEC PGM=yourpgm,PARM='RTEREUS(ON)/any le parms if u have'

Here are some old topics on migration

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/DFSpeCSKUog 

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/_QnqYPU3eIk


Thanks,
Kolusu



From:   "Pommier, Rex" <rpomm...@sfgmembers.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   02/01/2017 03:41 PM
Subject:    COBOL/LE question
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Hello all,

We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into
an issue with our COBOL and LE environment.  We are running COBOL 4.2.
Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM
introduced the warning message "IGZ0268W An invocation was made of OS/VS
COBOL program XXX." along with providing a usermod that can be installed
to suppress the message.  Normally that is OK but we have an ancient load
module written partially in OS/VS COBOL and partially in assembler that has
a home-grown ESTAE routine attached to it.  This program has consistently
failed spectacularly while testing it under 2.2. 
Here's the sequence of events.

13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   <<<< 
4 normal messages issued at start of run
13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001
13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED
13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 
(LE)  <<<< first abend message

$HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 
+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. 
+CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406
  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 0043D9A8 0043D668 0043D668 00433038 
  GPR 4-7 0043D38C 0043D698 00433038 0043D658 
  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 
  GPR C-F 0042AC30 0043D490 804340DA 966F4958 
+CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407
  WHILE RUNNING PROGRAM UNKNOWN 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 00441DE0 00441AA0 00441AA0 00433038 
  GPR 4-7 0044187C 00441AD0 00433038 00441A90 
  GPR 8-B 0042CED0 0008 0045D050 9687F3B0 
  GPR C-F 0042AC30 004418C8 804340DA 966F4958 
  FLT 0-2 49310F59C000  4E00030869B8 
  FLT 4-6 4E025368  

IEA995I SYMPTOM DUMP OUTPUT  417
  USER COMPLETION CODE=4087 REASON CODE=
 TIME=13.06.50  SEQ=00312  CPU=  ASID=0045 
 PSW AT TIME OF ERROR  078D1000   966A5806  ILC 2  INTC 0D 
   ACTIVE LOAD MODULE   ADDRESS=1660D410  OFFSET=000983F6 
   NAME=CEEPLPKA 
   DATA AT PSW  166A5800 - 00181610  0A0DA7F4  001C1811 
   GR 0: 8400   1: 84000FF7 
  2:    3: 00433038 
  4: 166E8398   5: 166E8A34 
  6: 00429358   7: 166A57CA 
  8: 8000   9: 00443EC6 
  A: 0001   B: 966A5728 
  C: 0042AC30   D: 00441EC8 
  E: 8043404E   F:  
 END OF SYMPTOM DUMP 
 

I'm not asking anybody to chase the dumps for me or anything like that, just
wondering if anybody has had issues like this while migrating to 2.2. 
 I added a STEPLIB to the job step to point to the 1.13 SCEERUN and
SCEERUN2 libraries and the program runs fine.  I've tried it with and
without the USERMOD designed to suppress the warning message about OS/VS
COBOL to no avail.  To make it even more bizarre, I even went so far as to
try it in my 1.13 system with a STEPLIB pointing to the 2.2 SCEERUN and
SCEERUN2 libraries to try to get it to fail and it didn't. 

Am I looking at the wrong place by looking at this IGZ0268W message?   Am 
I mi

Re: COBOL/LE question

[Pommier, Rex]

Hi Kolusu,

Thanks for the idea.  Unfortunately it made no difference.  The initial driver 
program being executed here is assembler which is calling COBOL programs.  
Looks like it is time to dig into an estae routine.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Wednesday, February 01, 2017 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

Rex,

I forgot to mention that DO NOT SET  RTEREUS(ON) as default.  Just set it for 
the particular job you are having problem with.

Something like this

//STEP0100  EXEC PGM=yourpgm,PARM='RTEREUS(ON)/any le parms if u have'

Here are some old topics on migration

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/DFSpeCSKUog 

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/_QnqYPU3eIk


Thanks,
Kolusu



From:   "Pommier, Rex" <rpomm...@sfgmembers.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   02/01/2017 03:41 PM
Subject:    COBOL/LE question
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Hello all,

We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into an 
issue with our COBOL and LE environment.  We are running COBOL 4.2.  Within the 
maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM introduced 
the warning message "IGZ0268W An invocation was made of OS/VS COBOL program 
XXX." along with providing a usermod that can be installed to suppress the 
message.  Normally that is OK but we have an ancient load module written 
partially in OS/VS COBOL and partially in assembler that has a home-grown ESTAE 
routine attached to it.  This program has consistently failed spectacularly 
while testing it under 2.2. 
Here's the sequence of events.

13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   <<<< 
4 normal messages issued at start of run
13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001
13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED
13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 
(LE)  <<<< first abend message

$HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 
+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. 
+CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406
  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 0043D9A8 0043D668 0043D668 00433038 
  GPR 4-7 0043D38C 0043D698 00433038 0043D658 
  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 
  GPR C-F 0042AC30 0043D490 804340DA 966F4958 
+CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407
  WHILE RUNNING PROGRAM UNKNOWN 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 00441DE0 00441AA0 00441AA0 00433038 
  GPR 4-7 0044187C 00441AD0 00433038 00441A90 
  GPR 8-B 0042CED0 0008 0045D050 9687F3B0 
  GPR C-F 0042AC30 004418C8 804340DA 966F4958 
  FLT 0-2 49310F59C000  4E00030869B8 
  FLT 4-6 4E025368  

IEA995I SYMPTOM DUMP OUTPUT  417
  USER COMPLETION CODE=4087 REASON CODE=
 TIME=13.06.50  SEQ=00312  CPU=  ASID=0045 
 PSW AT TIME OF ERROR  078D1000   966A5806  ILC 2  INTC 0D 
   ACTIVE LOAD MODULE   ADDRESS=1660D410  OFFSET=000983F6 
   NAME=CEEPLPKA 
   DATA AT PSW  166A5800 - 00181610  0A0DA7F4  001C1811 
   GR 0: 8400   1: 84000FF7 
  2:    3: 00433038 
  4: 166E8398   5: 166E8A34 
  6: 00429358   7: 166A57CA 
  8: 8000   9: 00443EC6 
  A: 0001   B: 966A5728 
  C: 0042AC30   D: 00441EC8 
  E: 8043404E   F:  
 END OF SYMPTOM DUMP 
 

I'm not asking anybody to chase the dumps for me or anything like that, just 
wondering if anybody has had issues like this while migrating to 2.2. 
 I added a STEPLIB to the job step to point to the 1.13 SCEERUN and
SCEERUN2 libraries and the program runs fine.  I've tried it with and without 
the USERMOD designed to suppress the warning message about OS/VS COBOL to no 
avail.  To make it even more bizarre, I even went so far as to try it in my 
1.13 system with a STEPLIB pointing to the 2.2 SCEERUN and
SCEERUN2 libraries to try to get it to fail and it didn't. 

Am I looking at the wrong place by looking at this IGZ0268W message?   Am 
I missing something obvious? 

Thanks for any advice you may be able to offer.

Rex 

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an em

Re: COBOL/LE question

[Sri h Kolusu]

Rex,

I forgot to mention that DO NOT SET  RTEREUS(ON) as default.  Just set it 
for the particular job you are having problem with.

Something like this

//STEP0100  EXEC PGM=yourpgm,PARM='RTEREUS(ON)/any le parms if u have'

Here are some old topics on migration

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/DFSpeCSKUog 

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/_QnqYPU3eIk


Thanks,
Kolusu



From:   "Pommier, Rex" <rpomm...@sfgmembers.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   02/01/2017 03:41 PM
Subject:    COBOL/LE question
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Hello all,

We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran 
into an issue with our COBOL and LE environment.  We are running COBOL 
4.2.  Within the maintenance for COBOL and the upgrade in LE from 1.13 to 
2.2, IBM introduced the warning message "IGZ0268W An invocation was made 
of OS/VS COBOL program XXX." along with providing a usermod that can 
be installed to suppress the message.  Normally that is OK but we have an 
ancient load module written partially in OS/VS COBOL and partially in 
assembler that has a home-grown ESTAE routine attached to it.  This 
program has consistently failed spectacularly while testing it under 2.2. 
Here's the sequence of events.

13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   <<<< 
4 normal messages issued at start of run
13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING  
13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001  
13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED  
13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 
(LE)  <<<< first abend message

$HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 
+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. 
+CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406 
  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 0043D9A8 0043D668 0043D668 00433038 
  GPR 4-7 0043D38C 0043D698 00433038 0043D658 
  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 
  GPR C-F 0042AC30 0043D490 804340DA 966F4958 
+CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407 
  WHILE RUNNING PROGRAM UNKNOWN 
  AT THE TIME OF INTERRUPT 
  PSW 0008 804340DA 
  GPR 0-3 00441DE0 00441AA0 00441AA0 00433038 
  GPR 4-7 0044187C 00441AD0 00433038 00441A90 
  GPR 8-B 0042CED0 0008 0045D050 9687F3B0 
  GPR C-F 0042AC30 004418C8 804340DA 966F4958 
  FLT 0-2 49310F59C000  4E00030869B8 
  FLT 4-6 4E025368  

IEA995I SYMPTOM DUMP OUTPUT  417 
  USER COMPLETION CODE=4087 REASON CODE= 
 TIME=13.06.50  SEQ=00312  CPU=  ASID=0045 
 PSW AT TIME OF ERROR  078D1000   966A5806  ILC 2  INTC 0D 
   ACTIVE LOAD MODULE   ADDRESS=1660D410  OFFSET=000983F6 
   NAME=CEEPLPKA 
   DATA AT PSW  166A5800 - 00181610  0A0DA7F4  001C1811 
   GR 0: 8400   1: 84000FF7 
  2:    3: 00433038 
  4: 166E8398   5: 166E8A34 
  6: 00429358   7: 166A57CA 
  8: 8000   9: 00443EC6 
  A: 0001   B: 966A5728 
  C: 0042AC30   D: 00441EC8 
  E: 8043404E   F:  
 END OF SYMPTOM DUMP 
 

I'm not asking anybody to chase the dumps for me or anything like that, 
just wondering if anybody has had issues like this while migrating to 2.2. 
 I added a STEPLIB to the job step to point to the 1.13 SCEERUN and 
SCEERUN2 libraries and the program runs fine.  I've tried it with and 
without the USERMOD designed to suppress the warning message about OS/VS 
COBOL to no avail.  To make it even more bizarre, I even went so far as to 
try it in my 1.13 system with a STEPLIB pointing to the 2.2 SCEERUN and 
SCEERUN2 libraries to try to get it to fail and it didn't. 

Am I looking at the wrong place by looking at this IGZ0268W message?   Am 
I missing something obvious? 

Thanks for any advice you may be able to offer.

Rex 

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message 
is not the intended recipient or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified 
that any disclosure, distribution, copying, or any action taken or action 
omitted in reliance on it, is strictly prohibited and may be unlawful.  If 
you have received this communication in error, please notify us 
immediately by replying to this message and destroy the material in its 
entiret

Re: COBOL/LE question

[Savor, Thomas (Alpharetta)]

IGZ0268W means that OS/VS COBOL is trying to interface with COBOL 5.  Which is 
a no-no.

Thanks,

Tom Savor
Software Developer, Sr
FRMS-SCM
Fiserv

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

Re: COBOL/LE question

[Jesse 1 Robinson]

The most common problem in a recovery routine is failure to restore registers 
properly. The older the code, the more likely you are to hit such a glitch. I 
once debugged a bizarre COBOL program error that was completely inexplicable. I 
set a SLIP trap for the 'first' error, which turned out to be a run of the mill 
S0C7 data problem. The program had an ancient assembler recovery routine that 
messed up the registers and took a wild branch into PLPA. My solution was to 
BR14 out the recovery routine rather than try to fix it. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, February 01, 2017 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: COBOL/LE question

i am guess the c/vs was nores nodynam and the asm90 is your real trouble maker

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:58, Steve Beaver <st...@stevebeaver.com> wrote:
> 
> Rex OS VS  call Wold to call Bob five is a big jump
> 
> Sent from my iPhone
> Steve Beaver
> 
> 
>> On Feb 1, 2017, at 16:55, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>> 
>> We're starting down that path.  Management doesn't want to have to recompile 
>> things but I'm thinking we may need to do so just to see if that's the 
>> problem.
>> 
>> Rex
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Steve Beaver
>> Sent: Wednesday, February 01, 2017 4:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL/LE question
>> 
>> I have a simple question do you happen to have a the source modules 
>> that if you attempted to reassemble them and recompile them to see if 
>> that's the problem
>> 
>> Sent from my iPhone
>> Steve Beaver
>> 
>> 
>>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, 
>>> IBM introduced the warning message "IGZ0268W An invocation was made of 
>>> OS/VS COBOL program XXX." along with providing a usermod that can be 
>>> installed to suppress the message.  Normally that is OK but we have an 
>>> ancient load module written partially in OS/VS COBOL and partially in 
>>> assembler that has a home-grown ESTAE routine attached to it.  This program 
>>> has consistently failed spectacularly while testing it under 2.2.  Here's 
>>> the sequence of events.
>>> 
>>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED  
>>>   <<<< 4 normal messages issued at start of run
>>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING  
>>>   
>> We're starting down that path.  Management doesn't want to have to recompile 
>> things but I'm thinking we may need to do so just to see if that's the 
>> problem.
>> 
>> Rex
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Steve Beaver
>> Sent: Wednesday, February 01, 2017 4:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL/LE question
>> 
>> I have a simple question do you happen to have a the source modules 
>> that if you attempted to reassemble them and recompile them to see if 
>> that's the problem
>> 
>> Sent from my iPhone
>> Steve Beaver
>> 
>> 
>>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, 
>>> IBM introduced the warning message "IGZ0268W An invocation was made of 
>>> OS/VS COBOL program XXX." along with providing a usermod that can be 
>>> installed to suppress the message.  Normally that is OK but we have an 
>>> ancient load module written partially in OS/VS COBOL and partially in 
>>> assembler that has a home-g

Re: COBOL/LE question

[Steve Beaver]

i am guess the c/vs was nores nodynam and the asm90 is your real trouble maker

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:58, Steve Beaver <st...@stevebeaver.com> wrote:
> 
> Rex OS VS  call Wold to call Bob five is a big jump
> 
> Sent from my iPhone
> Steve Beaver 
> 
> 
>> On Feb 1, 2017, at 16:55, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>> 
>> We're starting down that path.  Management doesn't want to have to recompile 
>> things but I'm thinking we may need to do so just to see if that's the 
>> problem.
>> 
>> Rex
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Steve Beaver
>> Sent: Wednesday, February 01, 2017 4:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL/LE question
>> 
>> I have a simple question do you happen to have a the source modules that if 
>> you attempted to reassemble them and recompile them to see if that's the 
>> problem
>> 
>> Sent from my iPhone
>> Steve Beaver 
>> 
>> 
>>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, 
>>> IBM introduced the warning message "IGZ0268W An invocation was made of 
>>> OS/VS COBOL program XXX." along with providing a usermod that can be 
>>> installed to suppress the message.  Normally that is OK but we have an 
>>> ancient load module written partially in OS/VS COBOL and partially in 
>>> assembler that has a home-grown ESTAE routine attached to it.  This program 
>>> has consistently failed spectacularly while testing it under 2.2.  Here's 
>>> the sequence of events.
>>> 
>>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED  
>>>   <<<< 4 normal messages issued at start of run
>>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING  
>>>   
>> We're starting down that path.  Management doesn't want to have to recompile 
>> things but I'm thinking we may need to do so just to see if that's the 
>> problem.
>> 
>> Rex
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Steve Beaver
>> Sent: Wednesday, February 01, 2017 4:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL/LE question
>> 
>> I have a simple question do you happen to have a the source modules that if 
>> you attempted to reassemble them and recompile them to see if that's the 
>> problem
>> 
>> Sent from my iPhone
>> Steve Beaver 
>> 
>> 
>>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, 
>>> IBM introduced the warning message "IGZ0268W An invocation was made of 
>>> OS/VS COBOL program XXX." along with providing a usermod that can be 
>>> installed to suppress the message.  Normally that is OK but we have an 
>>> ancient load module written partially in OS/VS COBOL and partially in 
>>> assembler that has a home-grown ESTAE routine attached to it.  This program 
>>> has consistently failed spectacularly while testing it under 2.2.  Here's 
>>> the sequence of events.
>>> 
>>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED  
>>>   <<<< 4 normal messages issued at start of run
>>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING  
>>>   
>>> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001   
>>>   
>>> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED 
>>>   
>>> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 
>>> (LE)  <<<< first abend message
>>> 
>>> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
>>>

Re: COBOL/LE question

[Steve Beaver]

Rex OS VS  call Wold to call Bob five is a big jump

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:55, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
> 
> We're starting down that path.  Management doesn't want to have to recompile 
> things but I'm thinking we may need to do so just to see if that's the 
> problem.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Steve Beaver
> Sent: Wednesday, February 01, 2017 4:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL/LE question
> 
> I have a simple question do you happen to have a the source modules that if 
> you attempted to reassemble them and recompile them to see if that's the 
> problem
> 
> Sent from my iPhone
> Steve Beaver 
> 
> 
>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>> 
>> Hello all,
>> 
>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
>> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
>> COBOL program XXX." along with providing a usermod that can be installed 
>> to suppress the message.  Normally that is OK but we have an ancient load 
>> module written partially in OS/VS COBOL and partially in assembler that has 
>> a home-grown ESTAE routine attached to it.  This program has consistently 
>> failed spectacularly while testing it under 2.2.  Here's the sequence of 
>> events.
>> 
>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   
>>  <<<< 4 normal messages issued at start of run
>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING   
>>  
> We're starting down that path.  Management doesn't want to have to recompile 
> things but I'm thinking we may need to do so just to see if that's the 
> problem.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Steve Beaver
> Sent: Wednesday, February 01, 2017 4:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL/LE question
> 
> I have a simple question do you happen to have a the source modules that if 
> you attempted to reassemble them and recompile them to see if that's the 
> problem
> 
> Sent from my iPhone
> Steve Beaver 
> 
> 
>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>> 
>> Hello all,
>> 
>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
>> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
>> COBOL program XXX." along with providing a usermod that can be installed 
>> to suppress the message.  Normally that is OK but we have an ancient load 
>> module written partially in OS/VS COBOL and partially in assembler that has 
>> a home-grown ESTAE routine attached to it.  This program has consistently 
>> failed spectacularly while testing it under 2.2.  Here's the sequence of 
>> events.
>> 
>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   
>>  <<<< 4 normal messages issued at start of run
>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING   
>>  
>> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001
>>  
>> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED  
>>  
>> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE) 
>>  <<<< first abend message
>> 
>> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
>> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
>> 
>> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
>> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
>> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>> WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
>> AT THE TIME OF INTERRUPT  
>> PSW 0008 804340DA 
>> GPR 0-3 0043D9A8 0

Re: COBOL/LE question

[Steve Beaver]

when all else fails you may have to do them one at a time as the problems crop 
up

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:55, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
> 
> We're starting down that path.  Management doesn't want to have to recompile 
> things but I'm thinking we may need to do so just to see if that's the 
> problem.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Steve Beaver
> Sent: Wednesday, February 01, 2017 4:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL/LE question
> 
> I have a simple question do you happen to have a the source modules that if 
> you attempted to reassemble them and recompile them to see if that's the 
> problem
> 
> Sent from my iPhone
> Steve Beaver 
> 
> 
>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
>> 
>> Hello all,
>> 
>> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
>> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
>> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
>> COBOL program XXX." along with providing a usermod that can be installed 
>> to suppress the message.  Normally that is OK but we have an ancient load 
>> module written partially in OS/VS COBOL and partially in assembler that has 
>> a home-grown ESTAE routine attached to it.  This program has consistently 
>> failed spectacularly while testing it under 2.2.  Here's the sequence of 
>> events.
>> 
>> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED   
>>  <<<< 4 normal messages issued at start of run
>> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING   
>>  

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

Re: COBOL/LE question

[Pommier, Rex]

We're starting down that path.  Management doesn't want to have to recompile 
things but I'm thinking we may need to do so just to see if that's the problem.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, February 01, 2017 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL/LE question

I have a simple question do you happen to have a the source modules that if you 
attempted to reassemble them and recompile them to see if that's the problem

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote:
> 
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to suppress the message.  Normally that is OK but we have an ancient load 
> module written partially in OS/VS COBOL and partially in assembler that has a 
> home-grown ESTAE routine attached to it.  This program has consistently 
> failed spectacularly while testing it under 2.2.  Here's the sequence of 
> events.
> 
> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED
> <<<< 4 normal messages issued at start of run
> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
> 
> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001 
> 
> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED   
> 
> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)  
> <<<< first abend message
> 
> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> 
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
>  AT THE TIME OF INTERRUPT  
>  PSW 0008 804340DA 
>  GPR 0-3 0043D9A8 0043D668 0043D668 00433038   
>  GPR 4-7 0043D38C 0043D698 00433038 0043D658   
>  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0   
>  GPR C-F 0042AC30 0043D490 804340DA 966F4958   
> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407  
>  WHILE RUNNING PROGRAM UNKNOWN 
>  AT THE TIME OF INTERRUPT  
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to suppress the message.  Normally that is OK but we have an ancient load 
> module written partially in OS/VS COBOL and partially in assembler that has a 
> home-grown ESTAE routine attached to it.  This program has consistently 
> failed spectacularly while testing it under 2.2.  Here's the sequence of 
> events.
> 
> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED
> <<<< 4 normal messages issued at start of run
> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
> 
> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001 
> 
> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED   
> 
> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)  
> <<<< first abend message
> 
> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> 
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT

Re: COBOL/LE question

[Steve Beaver]

I have a simple question do you happen to have a the source modules that if you 
attempted to reassemble them and recompile them to see if that's the problem

Sent from my iPhone
Steve Beaver 


> On Feb 1, 2017, at 16:41, Pommier, Rex  wrote:
> 
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to suppress the message.  Normally that is OK but we have an ancient load 
> module written partially in OS/VS COBOL and partially in assembler that has a 
> home-grown ESTAE routine attached to it.  This program has consistently 
> failed spectacularly while testing it under 2.2.  Here's the sequence of 
> events.
> 
> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED
>  4 normal messages issued at start of run
> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
> 
> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001 
> 
> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED   
> 
> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)  
>  first abend message
> 
> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> 
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
>  AT THE TIME OF INTERRUPT  
>  PSW 0008 804340DA 
>  GPR 0-3 0043D9A8 0043D668 0043D668 00433038   
>  GPR 4-7 0043D38C 0043D698 00433038 0043D658   
>  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0   
>  GPR C-F 0042AC30 0043D490 804340DA 966F4958   
> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407  
>  WHILE RUNNING PROGRAM UNKNOWN 
>  AT THE TIME OF INTERRUPT  
> Hello all,
> 
> We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into 
> an issue with our COBOL and LE environment.  We are running COBOL 4.2.  
> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM 
> introduced the warning message "IGZ0268W An invocation was made of OS/VS 
> COBOL program XXX." along with providing a usermod that can be installed 
> to suppress the message.  Normally that is OK but we have an ancient load 
> module written partially in OS/VS COBOL and partially in assembler that has a 
> home-grown ESTAE routine attached to it.  This program has consistently 
> failed spectacularly while testing it under 2.2.  Here's the sequence of 
> events.
> 
> 13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED
>  4 normal messages issued at start of run
> 13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING
> 
> 13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001 
> 
> 13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED   
> 
> 13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)  
>  first abend message
> 
> $HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> 
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
>  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
>  AT THE TIME OF INTERRUPT  
>  PSW 0008 804340DA 
>  GPR 0-3 0043D9A8 0043D668 0043D668 00433038   
>  GPR 4-7 0043D38C 0043D698 00433038 0043D658   
>  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0   
>  GPR C-F 0042AC30 0043D490 804340DA 966F4958   
> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407  
>  WHILE RUNNING PROGRAM UNKNOWN 
>  AT THE TIME OF INTERRUPT  
>  

COBOL/LE question

[Pommier, Rex]

Hello all,

We are in the process of migrating from z/OS 1.13 to 2.2.  We just ran into an 
issue with our COBOL and LE environment.  We are running COBOL 4.2.  Within the 
maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, IBM introduced 
the warning message "IGZ0268W An invocation was made of OS/VS COBOL program 
XXX." along with providing a usermod that can be installed to suppress the 
message.  Normally that is OK but we have an ancient load module written 
partially in OS/VS COBOL and partially in assembler that has a home-grown ESTAE 
routine attached to it.  This program has consistently failed spectacularly 
while testing it under 2.2.  Here's the sequence of events.

13.04.12 JOB01549  +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED  
   4 normal messages issued at start of run
13.04.12 JOB01549  +TRBCYCLE: BEGIN PROCESSING  
  
13.04.12 JOB01549  +TRBCYCLE: LIMIT=  900.00 SECONDS EACH 001   
  
13.04.13 JOB01549  +TRBCYCLE: 20 ABENDS ALLOWED 
  
13.06.37 JOB01549  +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 (LE)
   first abend message

$HASP375 DCD110   ESTIMATED  LINES EXCEEDED (a bunch of these)
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110   
+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.  
+CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 0001  406  
  WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT 1687F3B0   
  AT THE TIME OF INTERRUPT  
  PSW 0008 804340DA 
  GPR 0-3 0043D9A8 0043D668 0043D668 00433038   
  GPR 4-7 0043D38C 0043D698 00433038 0043D658   
  GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0   
  GPR C-F 0042AC30 0043D490 804340DA 966F4958   
+CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 0002  407  
  WHILE RUNNING PROGRAM UNKNOWN 
  AT THE TIME OF INTERRUPT  
  PSW 0008 804340DA 
  GPR 0-3 00441DE0 00441AA0 00441AA0 00433038   
  GPR 4-7 0044187C 00441AD0 00433038 00441A90   
  GPR 8-B 0042CED0 0008 0045D050 9687F3B0   
  GPR C-F 0042AC30 004418C8 804340DA 966F4958   
  FLT 0-2 49310F59C000  4E00030869B8
  FLT 4-6 4E025368  

IEA995I SYMPTOM DUMP OUTPUT  417   
  USER COMPLETION CODE=4087 REASON CODE=   
 TIME=13.06.50  SEQ=00312  CPU=  ASID=0045 
 PSW AT TIME OF ERROR  078D1000   966A5806  ILC 2  INTC 0D 
   ACTIVE LOAD MODULE   ADDRESS=1660D410  OFFSET=000983F6  
   NAME=CEEPLPKA   
   DATA AT PSW  166A5800 - 00181610  0A0DA7F4  001C1811
   GR 0: 8400   1: 84000FF7
  2:    3: 00433038
  4: 166E8398   5: 166E8A34
  6: 00429358   7: 166A57CA
  8: 8000   9: 00443EC6
  A: 0001   B: 966A5728
  C: 0042AC30   D: 00441EC8
  E: 8043404E   F: 
 END OF SYMPTOM DUMP   
 

I'm not asking anybody to chase the dumps for me or anything like that, just 
wondering if anybody has had issues like this while migrating to 2.2.  I added 
a STEPLIB to the job step to point to the 1.13 SCEERUN and SCEERUN2 libraries 
and the program runs fine.  I've tried it with and without the USERMOD designed 
to suppress the warning message about OS/VS COBOL to no avail.  To make it even 
more bizarre, I even went so far as to try it in my 1.13 system with a STEPLIB 
pointing to the 2.2 SCEERUN and SCEERUN2 libraries to try to get it to fail and 
it didn't.  

Am I looking at the wrong place by looking at this IGZ0268W message?   Am I 
missing something obvious?  

Thanks for any advice you may be able to offer.

Rex   

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted 

Re: LE question

[Scott Ford]

Charles,

an excellent question ...I have to dig through documentation and figure out
which option overrides which.

Scott

On Thu, Nov 26, 2015 at 11:33 PM, Charles Mills <charl...@mcn.org> wrote:

> Does not CEEOPTS etc. still override? A good thing if you want it; a bad
> thing if you don't.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hank Oerlemans
> Sent: Thursday, November 26, 2015 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> If it's that sensitive then linking in your own options module would be a
> good idea.
>
> --
> 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: LE question

[Hank Oerlemans]

If it's that sensitive then linking in your own options module would be a good 
idea.
 
IMO
 
Hank 

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

LE question

[Scott Ford]

All,

I have a new to verify the correct LE runoption are in effect prior to our
STCs initialization.
I need to check things like:

1.ALL31
2.   HEAP
3.   STACK

I would like to do this pro grammatically. Can i do this ?
If I can , can some point me the direction of a manual which mentions it ?

Regards,
Scott
www.idmworks.com

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

Re: LE question

[Charles Mills]

I think Scott is the vendor and is worried about the customer doing a 
PARM='some LE option/...' or a //CEEOPTS DD and then calling their support when 
the STC does not perform as desired. Or at least confusing their support desk 
because things are not exactly as the vendor expects.

I don't know of a solution but it would be a nice thing -- an LE service to 
return all of the options currently in effect.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 26, 2015 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in 
Parmlib or CEEOPT module in the code.  Generally - one size fits all.  In 
CEEPRMxx are parms for CICS, Other, and I am not sure if there is another 
delineation or not.

So depending on the environment - I would start with SYS1.PARMLIB and CEEPRMxx 
- see if it is there.

Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option 
parameters)>Statements/parameters for CEEPRMxx

Not sure about programmatically.  Most STCs should be using the system defined 
CEEPRMxx.  However that is not to say a vendor did not create their own CEEDOPT 
and link it into the STC.

You can issue a D CEE,ALL command through the console z/OS 2.1.0>z/OS MVS>z/OS 
MVS System Commands>MVS system commands reference>DISPLAY command>Displaying 
the current system level language environment run-time options

For CICS you can enter the CLER trans.

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

Re: LE question

[Hank Oerlemans]

If you can assume R12 point to the CAA then:

USING CEECAA,12 
USING CEEEDB,11 
USING CEEOCB,10 
L 11,CEECAAEDB 
L 10,CEEEDBOPTCB
CEECAA 
CEEEDB 
CEEOCB  

then use the following information to parse 

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/appocb.htm?lang=en

If you need to find the CAA then use "CEEARLU — anchor lookup"

Cheers Hank


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

Re: LE question

[Scott Ford]

Hank:

Much appreciated , exactly what I needed.

Regards,
Scott
IDMworks

On Thu, Nov 26, 2015 at 5:13 PM, Hank Oerlemans  wrote:

> If you can assume R12 point to the CAA then:
>
> USING CEECAA,12
> USING CEEEDB,11
> USING CEEOCB,10
> L 11,CEECAAEDB
> L 10,CEEEDBOPTCB
> CEECAA
> CEEEDB
> CEEOCB
>
> then use the following information to parse
>
>
> https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/appocb.htm?lang=en
>
> If you need to find the CAA then use "CEEARLU — anchor lookup"
>
> Cheers Hank
>
>
> --
> 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: LE question

[Lizette Koehler]

The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in 
Parmlib or 
CEEOPT module in the code.  Generally - one size fits all.  In CEEPRMxx are 
parms for CICS, Other, and I am not sure if there is another delineation or not.

So depending on the environment - I would start with SYS1.PARMLIB and CEEPRMxx 
- see if it is there.

Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option 
parameters)>Statements/parameters for CEEPRMxx

Not sure about programmatically.  Most STCs should be using the system defined 
CEEPRMxx.  However that is not to say a vendor did not create their own CEEDOPT 
and link it into the STC.

You can issue a D CEE,ALL command through the console
z/OS 2.1.0>z/OS MVS>z/OS MVS System Commands>MVS system commands 
reference>DISPLAY command>Displaying the current system level language 
environment run-time options

For CICS you can enter the CLER trans.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Scott Ford
> Sent: Thursday, November 26, 2015 1:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LE question
> 
> All,
> 
> I have a new to verify the correct LE runoption are in effect prior to our 
> STCs
> initialization.
> I need to check things like:
> 
> 1.ALL31
> 2.   HEAP
> 3.   STACK
> 
> I would like to do this pro grammatically. Can i do this ?
> If I can , can some point me the direction of a manual which mentions it ?
> 
> Regards,
> Scott
> www.idmworks.com

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

Re: LE question

[Scott Ford]

Charles:

Absolutely correct, I am going to write it and then share ,,if you guys
want me to...

Regards,
Scott

On Thu, Nov 26, 2015 at 4:53 PM, Charles Mills <charl...@mcn.org> wrote:

> I think Scott is the vendor and is worried about the customer doing a
> PARM='some LE option/...' or a //CEEOPTS DD and then calling their support
> when the STC does not perform as desired. Or at least confusing their
> support desk because things are not exactly as the vendor expects.
>
> I don't know of a solution but it would be a nice thing -- an LE service
> to return all of the options currently in effect.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, November 26, 2015 1:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> The parms are controlled via (depending on the z/OS Level) a CEEPRMxx
> member in Parmlib or CEEOPT module in the code.  Generally - one size fits
> all.  In CEEPRMxx are parms for CICS, Other, and I am not sure if there is
> another delineation or not.
>
> So depending on the environment - I would start with SYS1.PARMLIB and
> CEEPRMxx - see if it is there.
>
> Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning
> Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option
> parameters)>Statements/parameters for CEEPRMxx
>
> Not sure about programmatically.  Most STCs should be using the system
> defined CEEPRMxx.  However that is not to say a vendor did not create their
> own CEEDOPT and link it into the STC.
>
> You can issue a D CEE,ALL command through the console z/OS 2.1.0>z/OS
> MVS>z/OS MVS System Commands>MVS system commands reference>DISPLAY
> command>Displaying the current system level language environment run-time
> options
>
> For CICS you can enter the CLER trans.
>
> --
> 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: LE question

[Charles Mills]

Does not CEEOPTS etc. still override? A good thing if you want it; a bad thing 
if you don't.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hank Oerlemans
Sent: Thursday, November 26, 2015 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

If it's that sensitive then linking in your own options module would be a good 
idea.

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

Re: LE Question

[Martin Packer]

More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 64-bit) 
memory map. That's the point of it.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Alan Young ayo...@teleport.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/03/2015 06:44
Subject:Re: LE Question
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



The C runtime I/O functions fopen(), fread(), fwrite(), etc. support 
hiperspace data if the fopen() file mode parameter 
type=memory(hiperspace) is specified.

The functions are callable from COBOL. You just have to setup the 
parameters for what C expects and compile with NODYNAM. On our system a 
test program will allocate up to 2GB before a runtime error occurs. I 
don't know if that's due to AMODE 31 restrictions or not. Until we get 
64 bit COBOL, I guess one can try to allocate multiple files to store 
2GB in each.

I don't know if you will need to pass the file stream pointer back and 
forth between the programs or if opening the file with the same 
parameters in both will access the same file... We don't have a C 
compiler to try that out.

Alan

Scott Ford wrote:
 Sam,

 Yeah I agree.  I might have to stay with QSAM file until we can write 
and
 test an API..
 Thanks a lot,

 As always much appreciated.

 Regards,
 Scott

 On Monday, March 9, 2015, Sam Siegel s...@pscsi.net wrote:

 
 OK ... that is a lot of data.

 Since an address space provides for just 2GB in the 31 bit range for 
code,
 data and system code, you cannot get 3GB in there.  You have the 
following
 choices:
 1) 1 or more data spaces
 2) 64bit memory
 3) some 31 bit data in current address space; remainder in dataspace(s)
 and/or 64bit memory.

 64 bit memory is the cleanest in terms of using linear addresses. 
However,
 if data needs to be referenced by COBOL, you will face problems.  You 
might
 need to copy back data to 31bit address space or other means.

 dataspaces cannot be directly accesses by COBOL as you need to be in AR
 mode and use the proper ALETs. COBOL does not do ALETs.

 If you go the 64 bit memory route.  You can create an API in c that 
will
 retrieve data on behalf of COBOL and copy it back to 31 bit memory.

 If you go the dataspace route, you can create an API in asm that will
 retrieve ALET qualified data on behalf of COBOL and copy it over to
 non-alet qualified memory.

 Either way, i think you need an API.

 On Mon, Mar 9, 2015 at 3:44 PM, Scott Ford idfzos...@gmail.com
 javascript:; wrote:

 
 Sam,

 2-3 G .

 Regards,
 Scott

 On Monday, March 9, 2015, Paul Gilmartin 
 000433f07816-dmarc-requ...@listserv.ua.edu javascript:; wrote:

 
 On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:

 
 How much data?  10meg?  100meg?  1gig?

 
 How about 10 gig?  None of those numbers would be unreasonable
 if COBOL supported 64-bit addressing.  But IBM can't see the use
 for that.

 Of course if the data are large enough they go into page data sets
 anyway, but that's utterly transparent to the programmer.

 
 On Mar 9, 2015 2:06 PM, Scott Ford wrote:
 
 I will have to read and try ..my question is how do i pass a lot of
 
 data
 
 ...a dataspace ? i would like to avoid dasd if I can ..
 
 -- gil
 

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: LE Question

[Martin Packer]

I wonder if Data Windowing Services is still around. I vaguely recall they 
used Hiperspaces (still perfectly valid but mapped to Central).

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Scott Ford idfzos...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/03/2015 01:37
Subject:Re: LE Question
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Sam,

Yeah I agree.  I might have to stay with QSAM file until we can write and
test an API..
Thanks a lot,

As always much appreciated.

Regards,
Scott

On Monday, March 9, 2015, Sam Siegel s...@pscsi.net wrote:

 OK ... that is a lot of data.

 Since an address space provides for just 2GB in the 31 bit range for 
code,
 data and system code, you cannot get 3GB in there.  You have the 
following
 choices:
 1) 1 or more data spaces
 2) 64bit memory
 3) some 31 bit data in current address space; remainder in dataspace(s)
 and/or 64bit memory.

 64 bit memory is the cleanest in terms of using linear addresses. 
However,
 if data needs to be referenced by COBOL, you will face problems.  You 
might
 need to copy back data to 31bit address space or other means.

 dataspaces cannot be directly accesses by COBOL as you need to be in AR
 mode and use the proper ALETs. COBOL does not do ALETs.

 If you go the 64 bit memory route.  You can create an API in c that 
will
 retrieve data on behalf of COBOL and copy it back to 31 bit memory.

 If you go the dataspace route, you can create an API in asm that will
 retrieve ALET qualified data on behalf of COBOL and copy it over to
 non-alet qualified memory.

 Either way, i think you need an API.

 On Mon, Mar 9, 2015 at 3:44 PM, Scott Ford idfzos...@gmail.com
 javascript:; wrote:

  Sam,
 
  2-3 G .
 
  Regards,
  Scott
 
  On Monday, March 9, 2015, Paul Gilmartin 
  000433f07816-dmarc-requ...@listserv.ua.edu javascript:; wrote:
 
   On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:
  
   How much data?  10meg?  100meg?  1gig?
   
   How about 10 gig?  None of those numbers would be unreasonable
   if COBOL supported 64-bit addressing.  But IBM can't see the use
   for that.
  
   Of course if the data are large enough they go into page data sets
   anyway, but that's utterly transparent to the programmer.
  
   On Mar 9, 2015 2:06 PM, Scott Ford wrote:
   
I will have to read and try ..my question is how do i pass a lot 
of
  data
...a dataspace ? i would like to avoid dasd if I can ..
  
   -- gil
  
   
--
   For IBM-MAIN subscribe / signoff / archive access instructions,
   send email to lists...@listserv.ua.edu javascript:; javascript:;
 with the message:
   INFO IBM-MAIN
  
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@listserv.ua.edu javascript:; with the 
message:
 INFO IBM-MAIN
 

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu javascript:; 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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: LE Question

[Scott Ford]

Alan:

I was thinking along the lines of what you suggested.  cant suggest as a
ISV and developer to customers to use CICS or DB2 as a solution.
I personally think its overkill for a system type application which we
are..besides we handle sensitive security type data.

Regards,
Scott

On Tue, Mar 10, 2015 at 2:06 AM, Timothy Sipples sipp...@sg.ibm.com wrote:

 There are LOTS of other potential options here. In no particular order,
 conceptually at least:

 1. CICS TS's containers probably provide what you need, conveniently,
 though you might have to chunk the data into containers of 2GB (or
 smaller) so that 31-bit COBOL can see them (and all of them). But you can
 have as many chunks as you wish, subject to whatever you've configured for
 MEMLIMIT. CICS TS Version 3.2 is most likely the minimum release for these
 purposes, though CICS TS 5.1 or higher would be desirable. CICS TS would
 manage the 64-bit storage for you, with lots of containers, while also
 providing 31-bit pointers to those individual containers as long as they're
 not too big. But the point (ahem) is that it's all in memory, so if you've
 got the real memory (and MEMLIMIT set accordingly) the containers will all
 live there.

 2. WebSphere MQ for z/OS could also be your chunker, as another option.

 3. Or you can pipe between programs, for example with BatchPipes.

 4. DB2 could be the intermediary. That'd work particularly well if you rely
 on DB2 to perform part of the work, for example some type of format
 conversion.

 Chunking or piping assume the data can be passed somewhat stream-like.
 If you're passing a single scanned image file -- maybe a picture of some
 part of the cosmos -- that's, say, 3GB in size, that's probably not
 something that's easily chunkable. But many things are.

 As always, if you think IBM ought to introduce a new feature or function,
 let IBM know:

 https://www.ibm.com/developerworks/rfe/


 
 Timothy Sipples
 IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
 E-Mail: sipp...@sg.ibm.com
 --
 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: LE Question

[Paul Gilmartin]

On Tue, 10 Mar 2015 09:37:42 +, Martin Packer wrote:

More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 64-bit)
memory map. That's the point of it.
 
Are you saying that it's there in case 64-bit is not enough?

-- gil

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

Re: LE Question

[Martin Packer]

Hiperspace came along about 22 years before 64-bit ANYTHING, let alone 
64-Bit Virtual.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/03/2015 12:29
Subject:Re: LE Question
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On Tue, 10 Mar 2015 09:37:42 +, Martin Packer wrote:

More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 
64-bit)
memory map. That's the point of it.
 
Are you saying that it's there in case 64-bit is not enough?

-- gil

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: LE Question

[Martin Packer]

Doability when you don't have a chance to do 64 Bit. :-( :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/03/2015 15:21
Subject:Re: LE Question
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On Tue, 10 Mar 2015 15:14:55 +, Martin Packer wrote:

Hiperspace came along about 22 years before 64-bit ANYTHING, let alone
64-Bit Virtual.
 
Nowadays, what advantage does hiperspace offer over 64-bit?
Performance, perhaps?

From:   Paul Gilmartin
Date:   10/03/2015 12:29

On Tue, 10 Mar 2015 09:37:42 +, Martin Packer wrote:

More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 
64-bit)
memory map. That's the point of it.

Are you saying that it's there in case 64-bit is not enough?

-- gil

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: LE Question

[Paul Gilmartin]

On Tue, 10 Mar 2015 15:14:55 +, Martin Packer wrote:

Hiperspace came along about 22 years before 64-bit ANYTHING, let alone
64-Bit Virtual.
 
Nowadays, what advantage does hiperspace offer over 64-bit?
Performance, perhaps?

From:   Paul Gilmartin
Date:   10/03/2015 12:29

On Tue, 10 Mar 2015 09:37:42 +, Martin Packer wrote:

More likely IEFUSI or similar. Hiperspace is NOT in the 31-bit (or 64-bit)
memory map. That's the point of it.

Are you saying that it's there in case 64-bit is not enough?

-- gil

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

Re: LE Question

[Alan Young]

The C runtime I/O functions fopen(), fread(), fwrite(), etc. support 
hiperspace data if the fopen() file mode parameter 
type=memory(hiperspace) is specified.


The functions are callable from COBOL. You just have to setup the 
parameters for what C expects and compile with NODYNAM. On our system a 
test program will allocate up to 2GB before a runtime error occurs. I 
don't know if that's due to AMODE 31 restrictions or not. Until we get 
64 bit COBOL, I guess one can try to allocate multiple files to store 
2GB in each.


I don't know if you will need to pass the file stream pointer back and 
forth between the programs or if opening the file with the same 
parameters in both will access the same file... We don't have a C 
compiler to try that out.


Alan

Scott Ford wrote:

Sam,

Yeah I agree.  I might have to stay with QSAM file until we can write and
test an API..
Thanks a lot,

As always much appreciated.

Regards,
Scott

On Monday, March 9, 2015, Sam Siegel s...@pscsi.net wrote:

  

OK ... that is a lot of data.

Since an address space provides for just 2GB in the 31 bit range for code,
data and system code, you cannot get 3GB in there.  You have the following
choices:
1) 1 or more data spaces
2) 64bit memory
3) some 31 bit data in current address space; remainder in dataspace(s)
and/or 64bit memory.

64 bit memory is the cleanest in terms of using linear addresses.  However,
if data needs to be referenced by COBOL, you will face problems.  You might
need to copy back data to 31bit address space or other means.

dataspaces cannot be directly accesses by COBOL as you need to be in AR
mode and use the proper ALETs. COBOL does not do ALETs.

If you go the 64 bit memory route.  You can create an API in c that will
retrieve data on behalf of COBOL and copy it back to 31 bit memory.

If you go the dataspace route, you can create an API in asm that will
retrieve ALET qualified data on behalf of COBOL and copy it over to
non-alet qualified memory.

Either way, i think you need an API.

On Mon, Mar 9, 2015 at 3:44 PM, Scott Ford idfzos...@gmail.com
javascript:; wrote:



Sam,

2-3 G .

Regards,
Scott

On Monday, March 9, 2015, Paul Gilmartin 
000433f07816-dmarc-requ...@listserv.ua.edu javascript:; wrote:

  

On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:



How much data?  10meg?  100meg?  1gig?

  

How about 10 gig?  None of those numbers would be unreasonable
if COBOL supported 64-bit addressing.  But IBM can't see the use
for that.

Of course if the data are large enough they go into page data sets
anyway, but that's utterly transparent to the programmer.



On Mar 9, 2015 2:06 PM, Scott Ford wrote:
  

I will have to read and try ..my question is how do i pass a lot of


data
  

...a dataspace ? i would like to avoid dasd if I can ..


-- gil



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

AW: Re: LE Question

[Peter Hunkeler]

One more potential option is the UNIX shared memory feature. I have not used 
this in any of my own programs, so I cannot say for sure it is an option in 
your case. Anyway, you might want to have a look.
There is a set of C functions called shmget(), shmat(), shmdt(), and shmctl(). 
A program creates the sharable area with shmget(), other programs map that 
storage into their own address space using shmat().
The idea is: The C routine would allocate the large area in 64bit storage, the 
Cobol routine would map part of it (mega byte chunks) into 31bit storage.
The Cobol program would need to call BPX1MAT for shmat() functions.

--Peter Hunkeler



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

Re: LE Question

[David Crayford]

On 10/03/2015 7:02 AM, Sam Siegel wrote:

64 bit memory is the cleanest in terms of using linear addresses.  However,
if data needs to be referenced by COBOL, you will face problems.  You might
need to copy back data to 31bit address space or other means.

dataspaces cannot be directly accesses by COBOL as you need to be in AR
mode and use the proper ALETs. COBOL does not do ALETs.


MVS callable services for HLLs has window services which can be used to 
access data-spaces or hiper-spaces in any language including COBOL.


http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieac100/ws.htm

Once you get your head around the abstraction they are very easy to use 
and not a ALET or access register in sight. We've used these services in 
one of our

products to access linear data sets and they work well.

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

LE Question

[Scott Ford]

I have a question about heaps. I want to have a Cobol program call a C
routine, the C routine to place data onto the heap  then return back to
Cobol. The question is can Cobol then reference that data ?

Regards,
Scott
www.identityforge.com

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

Re: LE Question

[Sam Siegel]

Scott - You will need to pass the address of the heap variable back to
COBOL. Then use set address of to associate the address with a COBOL
linkage section entry.

You may also need to take into consideration how LE clean's up the heap.
Depending on which heap the variable is created in, the life time of that
heap may be different that what you expect.

Look in the LE programming guide (ceea2190) chapter 14 for details.

Sam

On Mon, Mar 9, 2015 at 9:08 AM, Scott Ford idfzos...@gmail.com wrote:

 I have a question about heaps. I want to have a Cobol program call a C
 routine, the C routine to place data onto the heap  then return back to
 Cobol. The question is can Cobol then reference that data ?

 Regards,
 Scott
 www.identityforge.com

 --
 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: LE Question

[Charles Mills]

A general answer is Yes. Heap data persists until you explicitly free it. Stack 
data pops when you return from a called routine.

That's a general answer. I don't know your specifics, and everything I know 
about pointers in COBOL could be engraved on the back of a postage stamp.

But in general, routine X can call routine Y passing a pointer variable. 
Routine Y can then allocate something on the heap (malloc or new) and place the 
address in the pointer variable. On return to X, the allocated area is (still) 
available to X.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Monday, March 09, 2015 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE Question

I have a question about heaps. I want to have a Cobol program call a C routine, 
the C routine to place data onto the heap  then return back to Cobol. The 
question is can Cobol then reference that data ?

Regards,
Scott
www.identityforge.com

--
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: LE Question

[Scott Ford]

Guys:

I will have to read and try ..my question is how do i pass a lot of data
...a dataspace ? i would like to avoid dasd if I can ..

Regards,
Scott

On Mon, Mar 9, 2015 at 12:29 PM, Sam Siegel s...@pscsi.net wrote:

 Scott - You will need to pass the address of the heap variable back to
 COBOL. Then use set address of to associate the address with a COBOL
 linkage section entry.

 You may also need to take into consideration how LE clean's up the heap.
 Depending on which heap the variable is created in, the life time of that
 heap may be different that what you expect.

 Look in the LE programming guide (ceea2190) chapter 14 for details.

 Sam

 On Mon, Mar 9, 2015 at 9:08 AM, Scott Ford idfzos...@gmail.com wrote:

  I have a question about heaps. I want to have a Cobol program call a C
  routine, the C routine to place data onto the heap  then return back to
  Cobol. The question is can Cobol then reference that data ?
 
  Regards,
  Scott
  www.identityforge.com
 
  --
  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: LE Question

[Sam Siegel]

How much data?  10meg?  100meg?  1gig?
On Mar 9, 2015 2:06 PM, Scott Ford idfzos...@gmail.com wrote:

 Guys:

 I will have to read and try ..my question is how do i pass a lot of data
 ...a dataspace ? i would like to avoid dasd if I can ..

 Regards,
 Scott

 On Mon, Mar 9, 2015 at 12:29 PM, Sam Siegel s...@pscsi.net wrote:

  Scott - You will need to pass the address of the heap variable back to
  COBOL. Then use set address of to associate the address with a COBOL
  linkage section entry.
 
  You may also need to take into consideration how LE clean's up the heap.
  Depending on which heap the variable is created in, the life time of that
  heap may be different that what you expect.
 
  Look in the LE programming guide (ceea2190) chapter 14 for details.
 
  Sam
 
  On Mon, Mar 9, 2015 at 9:08 AM, Scott Ford idfzos...@gmail.com wrote:
 
   I have a question about heaps. I want to have a Cobol program call a C
   routine, the C routine to place data onto the heap  then return back to
   Cobol. The question is can Cobol then reference that data ?
  
   Regards,
   Scott
   www.identityforge.com
  
   --
   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: LE Question

[Paul Gilmartin]

On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:

How much data?  10meg?  100meg?  1gig?

How about 10 gig?  None of those numbers would be unreasonable
if COBOL supported 64-bit addressing.  But IBM can't see the use
for that.

Of course if the data are large enough they go into page data sets
anyway, but that's utterly transparent to the programmer.

On Mar 9, 2015 2:06 PM, Scott Ford wrote:

 I will have to read and try ..my question is how do i pass a lot of data
 ...a dataspace ? i would like to avoid dasd if I can ..

-- gil

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

Re: LE Question

[Scott Ford]

Sam,

2-3 G .

Regards,
Scott

On Monday, March 9, 2015, Paul Gilmartin 
000433f07816-dmarc-requ...@listserv.ua.edu wrote:

 On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:

 How much data?  10meg?  100meg?  1gig?
 
 How about 10 gig?  None of those numbers would be unreasonable
 if COBOL supported 64-bit addressing.  But IBM can't see the use
 for that.

 Of course if the data are large enough they go into page data sets
 anyway, but that's utterly transparent to the programmer.

 On Mar 9, 2015 2:06 PM, Scott Ford wrote:
 
  I will have to read and try ..my question is how do i pass a lot of data
  ...a dataspace ? i would like to avoid dasd if I can ..

 -- gil

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu javascript:; 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: LE Question

[Sam Siegel]

OK ... that is a lot of data.

Since an address space provides for just 2GB in the 31 bit range for code,
data and system code, you cannot get 3GB in there.  You have the following
choices:
1) 1 or more data spaces
2) 64bit memory
3) some 31 bit data in current address space; remainder in dataspace(s)
and/or 64bit memory.

64 bit memory is the cleanest in terms of using linear addresses.  However,
if data needs to be referenced by COBOL, you will face problems.  You might
need to copy back data to 31bit address space or other means.

dataspaces cannot be directly accesses by COBOL as you need to be in AR
mode and use the proper ALETs. COBOL does not do ALETs.

If you go the 64 bit memory route.  You can create an API in c that will
retrieve data on behalf of COBOL and copy it back to 31 bit memory.

If you go the dataspace route, you can create an API in asm that will
retrieve ALET qualified data on behalf of COBOL and copy it over to
non-alet qualified memory.

Either way, i think you need an API.

On Mon, Mar 9, 2015 at 3:44 PM, Scott Ford idfzos...@gmail.com wrote:

 Sam,

 2-3 G .

 Regards,
 Scott

 On Monday, March 9, 2015, Paul Gilmartin 
 000433f07816-dmarc-requ...@listserv.ua.edu wrote:

  On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:
 
  How much data?  10meg?  100meg?  1gig?
  
  How about 10 gig?  None of those numbers would be unreasonable
  if COBOL supported 64-bit addressing.  But IBM can't see the use
  for that.
 
  Of course if the data are large enough they go into page data sets
  anyway, but that's utterly transparent to the programmer.
 
  On Mar 9, 2015 2:06 PM, Scott Ford wrote:
  
   I will have to read and try ..my question is how do i pass a lot of
 data
   ...a dataspace ? i would like to avoid dasd if I can ..
 
  -- gil
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@listserv.ua.edu javascript:; 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: LE Question

[Scott Ford]

Sam,

Yeah I agree.  I might have to stay with QSAM file until we can write and
test an API..
Thanks a lot,

As always much appreciated.

Regards,
Scott

On Monday, March 9, 2015, Sam Siegel s...@pscsi.net wrote:

 OK ... that is a lot of data.

 Since an address space provides for just 2GB in the 31 bit range for code,
 data and system code, you cannot get 3GB in there.  You have the following
 choices:
 1) 1 or more data spaces
 2) 64bit memory
 3) some 31 bit data in current address space; remainder in dataspace(s)
 and/or 64bit memory.

 64 bit memory is the cleanest in terms of using linear addresses.  However,
 if data needs to be referenced by COBOL, you will face problems.  You might
 need to copy back data to 31bit address space or other means.

 dataspaces cannot be directly accesses by COBOL as you need to be in AR
 mode and use the proper ALETs. COBOL does not do ALETs.

 If you go the 64 bit memory route.  You can create an API in c that will
 retrieve data on behalf of COBOL and copy it back to 31 bit memory.

 If you go the dataspace route, you can create an API in asm that will
 retrieve ALET qualified data on behalf of COBOL and copy it over to
 non-alet qualified memory.

 Either way, i think you need an API.

 On Mon, Mar 9, 2015 at 3:44 PM, Scott Ford idfzos...@gmail.com
 javascript:; wrote:

  Sam,
 
  2-3 G .
 
  Regards,
  Scott
 
  On Monday, March 9, 2015, Paul Gilmartin 
  000433f07816-dmarc-requ...@listserv.ua.edu javascript:; wrote:
 
   On Mon, 9 Mar 2015 14:18:15 -0700, Sam Siegel wrote:
  
   How much data?  10meg?  100meg?  1gig?
   
   How about 10 gig?  None of those numbers would be unreasonable
   if COBOL supported 64-bit addressing.  But IBM can't see the use
   for that.
  
   Of course if the data are large enough they go into page data sets
   anyway, but that's utterly transparent to the programmer.
  
   On Mar 9, 2015 2:06 PM, Scott Ford wrote:
   
I will have to read and try ..my question is how do i pass a lot of
  data
...a dataspace ? i would like to avoid dasd if I can ..
  
   -- gil
  
   --
   For IBM-MAIN subscribe / signoff / archive access instructions,
   send email to lists...@listserv.ua.edu javascript:; javascript:;
 with the message:
   INFO IBM-MAIN
  
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@listserv.ua.edu javascript:; with the message:
 INFO IBM-MAIN
 

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu javascript:; 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