AW: Re: How does COBOL detect a recursive call?

[Peter Hunkeler]

> I'm a bit OCD about trying to make all my code RENT,REUS. My main way to 
> think of this is "would this still run correctly if it were burned into ROM?" 
> I try to make the answer to that YES.​ 
 
 
Put all your RENT modules into an APF authorized load library. No AC(1) 
required! The code will be loaded into subpool 252 key 0 storage. It will blow 
up with S0C4-4 if not really reentrant.


--
Peter Hunkeler



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

IBM's Australian cloud is in deep dodo

[Edward Gould]

http://www.theregister.co.uk/2016/08/09/australian_census_slips_in_the_ibm_cloud/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AST tracking help - OA47207

[Jake Anderson]

Hi,

I am unable to open the AST tracking link to know when there will be a GA
PTF for the APAR OA47207.

Could someone please help ?

Jake

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

Re: Enterprise COBOL API for dynamic capacity tables

[David Crayford]

I run Git for Windows on my work PC which is very good indeed. It has a 
bash shell emulator and a nice GUI. We use SMB on z/OS and map the 
network drives on windows, so it's easy to use git from the command line 
with the working directory mapping to the zFS file system. It's simple 
to push/pull stuff from/to github. We have a private github account and 
it's a great platform for development. We use the issue tracking system 
to create a backlog of work items. The tooling on github is superb.


I've recently been using a beta version of Windows 10 that has an 
integrated Ubuntu Linux VM running so I can use bash natively 
https://msdn.microsoft.com/en-us/commandline/wsl/about. It's great, much 
better than VirtualBox running VMs or Cygwin. It's a smart move by 
Microsoft. All the young kids are working on open source these days and 
they all uses macs because of the toolset, bash, homebrew etc. By 
integrating a Linux subsystem into Windows they may attract hipster 
hackers back the platform. Desktop Linux is ok but it's nowhere near as 
polished as iOS or Windows.



On 10/08/2016 1:27 AM, Frank Swarbrick wrote:

Can you clarify?  Do you run 'git' on Windows (I assume) and specify SMB 
folders that actually exist on USS as your local repository (or whatever its 
called)?

Sounds interesting.  Of course we don't use z/OS SMB, so that's an, umm, 
"opportunity".  :-)

Frank

From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Tuesday, August 9, 2016 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL API for dynamic capacity tables

On 9/08/2016 11:49 PM, John McKown wrote:

On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:


Since I developed it at work for work I'll have to ask my employer about
that.  Of course perhaps I should have asked before posting it publicly,
but that's water under the bridge now!

Sidetracking, has anyone used GitHub for z/OS production source
repository.  Meaning interacting with it directly from the mainframe?  All
of our distributed development groups use it, and it might be nice if we
could use it as well.


Just as a personal observation, I'd think that this would be difficult.
Someone would need to port the "git" command to z/OS. And that would likely
be a major undertaking since it uses the GNU tools to do a lot of it's
setup. It may also depend on some gcc (GNU compiler) specific
functionality. And, even if it is ported, there is the historic ASCII (UTF
actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
I've read about due to the Windows CRLF vs UNIX LF-only line ending causing
"problems".


I use git for z/OS UNIX stuff via SMB and it works well from a PC shell.
A script that mirrors PDS libraries should work.


Frank



--
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: Delta Outage

[Steve Beaver]

They need a z13 that can handle it all and some.  Add 750TB of storage and
Put all the zLinux servers on one box


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Linda
Sent: Tuesday, August 9, 2016 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delta Outage

Apparently Delta needs a couple of mainframes and GDPS or maybe metro mirror
instead. ;). 

Linda

Sent from my iPhone

> On Aug 9, 2016, at 9:06 AM, Gerhard Adam  wrote:
> 
> Apparently there are 500 servers involved.  I have my own speculations 
> as to why they didn't declare a disaster.
> 
> As a result, the outage was extended because it appears to be taking 
> them in excess of 12 hours to reboot everything.
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> Then WHY did they not initiate their DR and move all systems to the 
> HOT Site.  I just finished putting in a System that has a RTO=RPO=0
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gerhard Adam
> Sent: Tuesday, August 9, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> From what I understand, it isn't a simple power outage, but rather a 
> fire in the data center.
> 
> http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-
> delta-
> airlines/
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delta Outage
> 
> I live in Texas and we have ERCOT, and Texas produces more wind energy 
> than
> 3 countries.  And Texas has NO Interconnects To other grids.  
> 
> It its reprehensible that Delta does not have enough battery power and 
> gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and 
> unless there is a major storm in that area does not lose power
> 
> --
> 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

--
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: Delta Outage

[Bill Johnson]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; }  Delta is too busy running their oil refinery!


Sent from Yahoo Mail for iPhone


On Tuesday, August 9, 2016, 6:44 PM, Linda  wrote:

Apparently Delta needs a couple of mainframes and GDPS or maybe metro mirror 
instead. ;). 

Linda

Sent from my iPhone

> On Aug 9, 2016, at 9:06 AM, Gerhard Adam  wrote:
> 
> Apparently there are 500 servers involved.  I have my own speculations as to
> why they didn't declare a disaster.
> 
> As a result, the outage was extended because it appears to be taking them in
> excess of 12 hours to reboot everything.
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> Then WHY did they not initiate their DR and move all systems to the HOT
> Site.  I just finished putting in a System that has a RTO=RPO=0 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard Adam
> Sent: Tuesday, August 9, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> From what I understand, it isn't a simple power outage, but rather a fire in
> the data center.
> 
> http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
> airlines/
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delta Outage
> 
> I live in Texas and we have ERCOT, and Texas produces more wind energy than
> 3 countries.  And Texas has NO Interconnects To other grids.  
> 
> It its reprehensible that Delta does not have enough battery power and
> gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
> unless there is a major storm in that area does not lose power  
> 
> --
> 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

--
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: PDS / PDS/e Question

[Paul Gilmartin]

On Tue, 9 Aug 2016 14:55:54 -0600, Roger Bolan wrote:

>Wouldn't amblist give you what you want?
>
>On Aug 6, 2016 4:52 PM, "Steve Beaver" wrote:
>
>> I want the control information/linkedit.
>>
In extremis, you might try:
INCLUDE -ATTR,-ALIASES,SYSLIB(MEMBER)

Discard the generated load module and scrape the needed information
from SYSPRINT.

Alternatively, you could investigate the Program Management API which
is probably what AMBLIST uses anyway.

-- gil

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

Re: Delta Outage

[Mitch Mccluhan]

 Linda:

I agree!!

 

Mitch McCluhan
mitc...@aol.com

 

 

-Original Message-
From: Linda 
To: IBM-MAIN 
Sent: Tue, Aug 9, 2016 5:45 pm
Subject: Re: Delta Outage

Apparently Delta needs a couple of mainframes and GDPS or maybe metro mirror 
instead. ;). 

Linda

Sent from my iPhone

> On Aug 9, 2016, at 9:06 AM, Gerhard Adam  wrote:
> 
> Apparently there are 500 servers involved.  I have my own speculations as to
> why they didn't declare a disaster.
> 
> As a result, the outage was extended because it appears to be taking them in
> excess of 12 hours to reboot everything.
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> Then WHY did they not initiate their DR and move all systems to the HOT
> Site.  I just finished putting in a System that has a RTO=RPO=0 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard Adam
> Sent: Tuesday, August 9, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> From what I understand, it isn't a simple power outage, but rather a fire in
> the data center.
> 
> http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
> airlines/
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delta Outage
> 
> I live in Texas and we have ERCOT, and Texas produces more wind energy than
> 3 countries.  And Texas has NO Interconnects To other grids.  
> 
> It its reprehensible that Delta does not have enough battery power and
> gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
> unless there is a major storm in that area does not lose power  
> 
> --
> 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

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

How does COBOL detect a recursive call?

[Bill Woodger]

OK, it is the RENT or REUS (either will do) on the link-edit/bindering.

Without RENT/REUS you get a new executable for free. With RENT/REUS you get to 
"share" the original program, but it is necessarily a "recursive" use, so you 
get the "IGZ0064S A recursive call to active program..." message. Which is why 
IBM say you must CANCEL before the CALL to the ENTRY, which you can't do if the 
CALL is to an ENTRY in the same program. PROGRAM-ID ... IS RECURSIVE "gets 
around" the IGZ0064S, so there won't be a second condition, which causes 
another, and another. So LE will be happy.

So, you've discovered a way to nearly get a CALL to an ENTRY point with an 
ALIAS to work like it used to :-) 

However, there is overhead. The recursive CALL will share WORKING-STORAGE, but 
pretty much everything else will be initialised on each CALL, and then all 
thrown away on each GOBACK (since it is not actually recursing). For a one-shot 
use, this will not matter.

Safe to use? Well, understanding how it works/doesn't work wasn't easy for me 
:-)

Here's an example of the generated code from the COBOL compiler showing the 
recursion checking:

ICM   2,15,336(9) IPCB=1+16 
L 11,40(0,12) PBL=1 
BC8,210(0,11) GN=6(0002E6)  
L 3,92(0,9)   TGTFIXD+92
L 15,244(0,3) V(IGZCMSG )   
LA1,206(0,10) PGMLIT AT +202
BASR  14,15 

PGMLIT AT +202 is X'40', which is the 64 for the IGZ message.

There is similar code generated for an ENTRY.

And here's the code from the GOBACK clearing up to say things will be OK for 
another CALL:

L 3,336(0,9)  IPCB=1+16   
S 3,0(0,12)   SYSLIT AT +0
ST3,336(0,9)  IPCB=1+16   

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

Re: Delta Outage

[Linda]

Apparently Delta needs a couple of mainframes and GDPS or maybe metro mirror 
instead. ;). 

Linda

Sent from my iPhone

> On Aug 9, 2016, at 9:06 AM, Gerhard Adam  wrote:
> 
> Apparently there are 500 servers involved.  I have my own speculations as to
> why they didn't declare a disaster.
> 
> As a result, the outage was extended because it appears to be taking them in
> excess of 12 hours to reboot everything.
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> Then WHY did they not initiate their DR and move all systems to the HOT
> Site.  I just finished putting in a System that has a RTO=RPO=0 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard Adam
> Sent: Tuesday, August 9, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delta Outage
> 
> From what I understand, it isn't a simple power outage, but rather a fire in
> the data center.
> 
> http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
> airlines/
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Tuesday, August 9, 2016 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delta Outage
> 
> I live in Texas and we have ERCOT, and Texas produces more wind energy than
> 3 countries.  And Texas has NO Interconnects To other grids.  
> 
> It its reprehensible that Delta does not have enough battery power and
> gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
> unless there is a major storm in that area does not lose power  
> 
> --
> 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

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

How does COBOL detect a recursive call?

[Bill Woodger]

Thanks :-)

Looks like your LE has about 10 levels of "depth". The handler is getting 
invoked, and then itself abending/raising a condition, so it gets invoked 
again, and does the same thing - until LE runs out of patience that was defined 
for it.

The IGZMSG is the module which informs of a run-time problem. You earlier 
mentioned a COBOL message about recursion? IGZMSG would cause the message to be 
output, and I was wondering if it was a 15S or a 64S IGZ message.

Basically, the handler has been entered twice. The first time presumably the 
intended one - and then again. Then it hits the "invalid recursion" problem, 
and just keeps triggering the handler.

I can't see that the initial use of the handler could trigger the "recursive" 
problem, because it should be an entirely separate executable from the "main" 
program. 

With RECURSIVE on the PROGRAM-ID, the handler will be entered twice still (I'm 
assuming) but since there is no code to deal with the second condition, it will 
be ignored by the handler. 

To confirm that the ENTRY is not actually being used recursively, that it is in 
a separate executable (only worth checking because if it isn't, this problem 
would be caused) I'd REDEFINES the PROCEDURE-POINTER as PIC X(9) and DISPLAY it 
after the SET. Before that SET I'd put another SET ... ENTRY ... to the "main" 
program-name, and again DISPLAY that.  The two addresses DISPLAYed should not 
be close together (address of the ENTRY should be further away than the address 
of the PROGRAM-ID, by at least the length of the program in its entirety).

Given that that checks out, I'd DISPLAY the information in the handler, and see 
how much appears. If two conditions are being presented, knowledge of the 
second condition will be useful.

Does your program on Git work, or exhibit the problem? If it doesn't exhibit 
the problem, what needs to be done to it to do so?

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

Re: SHARE Atlanta proceedings

[Jesse 1 Robinson]

According to SHARE HQ, they give speakers some time to get their pitches 
uploaded (maybe with post-session tweaks) before posting a link on the web 
site. No specific ETA, but it should be soon. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, August 09, 2016 5:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SHARE Atlanta proceedings

Skip,

While I was aware of that link, the look and feel this time around was 
different enough that I thought there might have been a content/path change. I 
downloaded quite a few yesterday, one at a time. Once I have reviewed those, 
I'll check back on that link.

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, August 08, 2016 7:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SHARE Atlanta proceedings

Proceedings eventually end up on this page:

http://www.share.org/page/proceedings

Atlanta is not there yet. I don't know the expected 'drop' date, but it should 
not be too far off. I downloaded a couple of PDFs today by going through the 
SHARE app. Again, it's one by one, but for something you really want in a 
hurry, it's an option. I was in a hurry. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Monday, August 08, 2016 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SHARE Atlanta proceedings

They are available from the Atlanta event page. Try this link:

http://www.share.org/atlanta-agenda

HTH

Mike


On 8 August 2016 at 15:39, Richards, Robert B. 
wrote:

> Does anyone know when the Atlanta SHARE Conference proceedings from 
> last week will be available?
>
> Bob
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
Mike Shorkend
m...@shorkend.com
http://hybrid-web.global.blackspider.com/urlwrap/?q=AXicE2RmqN3EwOC5n4GhKKfSwDJdr7ioTC83MTMnOT-vpCg_Ry85P5eh1NzCz8_Rw8PA0NzI3JAhKD8ptahELygzOSOxKKXYwT_AV8_dP4who6SkwEpfv7y8XK84I78oOzUvBaydgeHhLgYGAAzQIiE
Tel: +972524208743
Fax: +97239772196


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

Re: How does COBOL detect a recursive call?

[John McKown]

On Tue, Aug 9, 2016 at 4:23 PM, Bill Woodger  wrote:

> Reading your post rather than going from the title, the U4087 2 is
> Language Environment abend for when an registered abend-handler has been
> entered a subsequent time before processing of the original abend has
> completed - the handler written in COBOL failed, and was entered again to
> process the failure.
>
> Can you show the IGZ message number that you got, please?
>
>
​16.33.31 JOB19047  +CEE0374C CONDITION=CEE0001S TOKEN=00030001 59C3C5C5
0001  048
   048   WHILE RUNNING PROGRAM CBLHDLR2 WHICH STARTS AT
0B200A18
   048   AT THE TIME OF INTERRUPT
   048   PSW 0008 800180D6
   048   GPR 0-3 00027330 00027118 0B292AC4 0B29226C
   048   GPR 4-7 00027128 0B29226C 00047488 00027118
   048   GPR 8-B 0002 0B292118 00047038 8B21DDE0
   048   GPR C-F 00021B88 00027150 800180D6 8514E450
16.33.31 JOB19047  +CEE0374C CONDITION=IGZ0064S TOKEN=00030040 59C9C7E9
0002  049
   049   WHILE RUNNING PROGRAM IGZCMSG  WHICH STARTS AT
8B26C058
   049   AT THE TIME OF INTERRUPT
   049   PSW 0008 800180D6
   049   GPR 0-3 0002AB60 0002A820 0002A820 00017038
   049   GPR 4-7 00017038 0002A850 00017038 0002A810
   049   GPR 8-B 00012A80 0B292118 00047038 8514F008
   049   GPR C-F 00021B88 0002AB60 800180D6 8514E450

The latter message repeats 10 times, with the 0002 at the end of the
first line incrementing by 1 each time until == 000B. Followed by:

16.33.31 JOB19047  IEA995I SYMPTOM DUMP OUTPUT  059
   059   USER COMPLETION CODE=4087 REASON CODE=0002
   059  TIME=16.33.31  SEQ=29342  CPU=  ASID=0051
   059  PSW AT TIME OF ERROR  078D1000   85108CEC  ILC 2  INTC
0D
   059NO ACTIVE MODULE FOUND
   059NAME=UNKNOWN
   059DATA AT PSW  05108CE6 - 00181610  0A0DA7F4  001C1811
   059GR 0: 8400   1: 84000FF7
   059   2: 0002   3: 00017038
   059   4: 05141E78   5: 05141FF0
   059   6: 00020340   7: 000207F0
   059   8: 8000   9: 00050FA6
   059   A: 0001   B: 85108C18
   059   C: 00021B88   D: 0004EFA8
   059   E: 8001804A   F: 0002
   059  END OF SYMPTOM DUMP
16.33.31 JOB19047  IEF450I TSH009A1 CBLHDLR2 - ABEND=S000 U4087
REASON=0002  060
​



-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

How does COBOL detect a recursive call?

[Bill Woodger]

Reading your post rather than going from the title, the U4087 2 is Language 
Environment abend for when an registered abend-handler has been entered a 
subsequent time before processing of the original abend has completed - the 
handler written in COBOL failed, and was entered again to process the failure.

Can you show the IGZ message number that you got, please?

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

Re: PDS / PDS/e Question

[Roger Bolan]

Wouldn't amblist give you what you want?

On Aug 6, 2016 4:52 PM, "Steve Beaver"  wrote:

> I want the control information/linkedit.
>
> Steve
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of retired mainframer
> Sent: Saturday, August 6, 2016 1:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS / PDS/e Question
>
> What data are you hoping to see?
>
> The first several records of a load module in a PDS normally contain
> control
> information and not the instructions/data that will appear in memory after
> the module is loaded.
>
> I don't know if the format of a program object in a PDSE has been publicly
> documented.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Steve Beaver
> > Sent: Saturday, August 06, 2016 9:23 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: PDS / PDS/e Question
> >
> > When reading thru a PDS / PDSe to pickup the first 60 bytes of a load
> > module.  I can get the DIRECTROY and do the POINT, and GET, but will
> > that get me to the first 60 bytes that I really Want in a RECFM U
> > Library?
>
> --
> 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: Enterprise COBOL API for dynamic capacity tables

[Frank Swarbrick]

Can you clarify?  Do you run 'git' on Windows (I assume) and specify SMB 
folders that actually exist on USS as your local repository (or whatever its 
called)?

Sounds interesting.  Of course we don't use z/OS SMB, so that's an, umm, 
"opportunity".  :-)

Frank

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Tuesday, August 9, 2016 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL API for dynamic capacity tables

On 9/08/2016 11:49 PM, John McKown wrote:
> On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
>
>> Since I developed it at work for work I'll have to ask my employer about
>> that.  Of course perhaps I should have asked before posting it publicly,
>> but that's water under the bridge now!
>>
>> Sidetracking, has anyone used GitHub for z/OS production source
>> repository.  Meaning interacting with it directly from the mainframe?  All
>> of our distributed development groups use it, and it might be nice if we
>> could use it as well.
>>
> Just as a personal observation, I'd think that this would be difficult.
> Someone would need to port the "git" command to z/OS. And that would likely
> be a major undertaking since it uses the GNU tools to do a lot of it's
> setup. It may also depend on some gcc (GNU compiler) specific
> functionality. And, even if it is ported, there is the historic ASCII (UTF
> actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
> I've read about due to the Windows CRLF vs UNIX LF-only line ending causing
> "problems".
>

I use git for z/OS UNIX stuff via SMB and it works well from a PC shell.
A script that mirrors PDS libraries should work.

>
>> Frank
>>
>>

--
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 2014 dynamic capacity tables

[Bernd Oppolzer]

At the moment I only look at one HANC (heap segment),
which is of limited size, depending on the HEAP parameters
on enclave startup. Typical size is from some KB to some MB.
For example, today I tested with 64 KB heap segment size,
which is pretty small.

That is, if you allocate several small areas which take (much) less than
64 KB, all is fine, and you will get a significant delta listing. Today, 
there

were only 11 areas of (in sum) 600 bytes, which were not freed on
the interesting function call. (This could anyway be a problem, if this 
function
is called several million times per day in an online environment; in 
fact it is

a function that gets a customer address from the DB2 database).

If a new heap segment is started between two calls, the delta listing
(as it is implemented at the moment) will look not so good. You can control
this by defining larger segment sizes.

Because the snapshot and the delta listing is limited to one HANC, it is
pretty fast.

You can take a snapshot of the whole heap chain, but there is no
delta listing of the whole heap chain at the moment. The delta listing
of the actual HANC seemed sufficient on the first shot.

Other parameters of the heap snapshot function are:

- which file handle for output? Default is stderr
- do you want size summary or not? (number of occupied and free areas,
total size)
- which size of every occupied area do you want to be dumped
(nothing at all, only the address and the length, or the first n bytes)?
- only the actual HANC or the whole heap chain?
- simple hex dump of the HANCs as a whole, or edited HANC (header info
with field names, individual areas and so on)

The implementation of the LE heap seems to be pretty stable over time;
the documentation is from 1997 and 2005, and the information is still 
valid;

so I guess there will be not much changes in the future. The algorithm is
from IBM Watson Research Center, see the presentation below.

Kind regards

Bernd



David Crayford schrieb:
Cool! So you run the heap control blocks and take snapshots? Does that 
work well when lots of memory is being allocated?



On 9/08/2016 9:16 PM, bernd.oppol...@t-online.de wrote:

No, I don't instrument at all.

I use my knowledge of the LE heap implementation (see the presentation
mentioned below) to store a map of all allocated and free areas at a 
given time
(area adresses and lengths) and then - some microseconds later - I 
compare that
with the new image then. Then I build a delta listing which shows all 
the areas
that have changed in the meantime, that is, which have been allocated 
and not freed.


If you call this before and after a critical function, you will see 
exactly

what areas are left "unfreed" by this function. This proved to be very
helpful in our environment, especially if the critical function is 
written
by another team. (I don't need to "instrument" the functions of the 
foreign team).


Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: COBOL 2014 dynamic capacity tables
Datum: 2016-08-09T13:53:15+0200
Von: "David Crayford" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

I  use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory
leaks. How is your instrumentation different? I assume you wrap
malloc()/free() calls?


On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:

IMO there is no need to create additional heaps
to support dynamic tables in COBOL.

I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something like "Stacks are easy,
heaps are fun"). There are COBOL examples included, which
use the LE functions CEEGTST (get storage) and CEEFRST
(free storage) - I hope, I recall the names correctly.

Based on these functions (which are malloc and free, after all),
you could do all sorts of dynamic allocations from COBOL, using
the normal LE "user heap", which is sufficient, IMO.

BTW: I wrote some functions in the last few days, which dumps all
the allocated heap areas and - more interesting - they write reports,
how the heap has changed since the last call. This is very interesting
...
if you have a function that you think that does not free its heap areas
properly, you can call this heap report function before and after
this function call and find out by looking at the so called heap delta
listing.

If you are interested, feel free to contact me offline.

Kind regards

Bernd





--
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: Enterprise COBOL API for dynamic capacity tables

[Frank Swarbrick]

John, this sounds like just the kind of challenge you are looking for!!  :-)


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Tuesday, August 9, 2016 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL API for dynamic capacity tables

On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Since I developed it at work for work I'll have to ask my employer about
> that.  Of course perhaps I should have asked before posting it publicly,
> but that's water under the bridge now!
>
> Sidetracking, has anyone used GitHub for z/OS production source
> repository.  Meaning interacting with it directly from the mainframe?  All
> of our distributed development groups use it, and it might be nice if we
> could use it as well.
>

Just as a personal observation, I'd think that this would be difficult.
Someone would need to port the "git" command to z/OS. And that would likely
be a major undertaking since it uses the GNU tools to do a lot of it's
setup. It may also depend on some gcc (GNU compiler) specific
functionality. And, even if it is ported, there is the historic ASCII (UTF
actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
I've read about due to the Windows CRLF vs UNIX LF-only line ending causing
"problems".



>
> Frank
>
>

--
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

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

Re: How does COBOL detect a recursive call?

[John McKown]

On Tue, Aug 9, 2016 at 11:28 AM, Mike Schwab 
wrote:

> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/
> com.ibm.zos.v2r1.ieab100/reus.htm
> When you link edit, you indicate the re-usability of the program.
> When the program runs, it reuses the same program if re-entrant.  Each
> use has a different set of registers and working storage.
> Serially reusable can be self modifying (storing into load module
> areas), but can be reused after completing.  Needs a new copy for a
> simultaneous use.
> None means the program must be reloaded from disk for every use.
>
> When you run a program, the LOAD macro examines the directory and
> loads as appropriate.
> http://www.longpelaexpertise.com/ezine/ReentrantBeginners.php
>
>
​That explains why my version of the program does what it does. I compile
my COBOL with the RENT compiler option, and use RENT,REUS on the link. So,
at least in my case, everything makes sense. I'm a bit OCD about trying to
make all my code RENT,REUS. My main way to think of this is "would this
still run correctly if it were burned into ROM?" I try to make the answer
to that YES.​



-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

sockets INIT call fails under systemrexx...

[Itschak Mugzach]

co-posted to IBM-Main & TCP-L...


I have a program running well on TSO, Batch and STC, but get rc 1004
(EIBMIUCVERR IUCV error) on INITIALIZE call. I have several versions of
this program in Rexx & asm, all get the same problem. some information:

   - Started task User has an OMVS segment.
   - IKJTSO00 was modified to have AXRRXWKD  in auth cmds. This should load
   a complete TMP environment.
   - The program (asm version) is caled from an APF authorized library.
   - the asm program get a similar msg says 'The proper z/OS UNIX
   environment is not setup. Init halted.'

​Any idea why sockets is not working for me under systemrexx?​

​Best,
ITschak ​

*| **Itschak Mugzach | Director | SecuriTeam Software | *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*

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

How does COBOL detect a recursive call?

[Bill Woodger]

Well, the SET ... TO ENTRY ... definitely loads (with the assumption that the 
module is not already in memory, in which case it just gives you the 
entry-point address). At least ordinarily. I don't know about the ENTRY which 
is in the same program. An ENTRY in a different program (with an ALIAS) should 
just act like any other module.

As to why it then wouldn't work... I guess it (the COBOL compiler) is being too 
clever, and it knows that your ENTRY is in the same program. Or, for the SET 
knows it is in the same program... or both... or something else. 

As I mentioned before, it is an interesting situation, but I can't see 
application beyond that - even if you work out how to get it going - with 
V3.4.x, there's not necessarily a guarantee that it will do the same thing with 
V5+. It is neither documented as working, nor documented as not working. That's 
a pretty wide grey area. If your site is the only one doing this, you're not 
going to get a fix for V8 that just happens to have come along and broken 
whatever you work out (if you work something out).

Have you a cast-iron reason for sticking with the ENTRY/ALIAS over the 
two-program approach?

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

Enterprise COBOL API for dynamic capacity tables

[Bill Woodger]

You could do POINTER arithmetic, but that is not supported directly either :-)

Because it is not supported, you have to use REDEFINES, which implies that you 
have to know the length of the POINTER. Compile a 31-bit POINTER with REDEFINES 
under a 64-bit-addressing compiler and... things don't go so well. OK, so we 
don't have 64-bits yet... 

So, on the assumption that it is only the length that is going to be 
problematic, a little bit of self-checking can be done.

And, that's a bad assumption for another reason. The field the actual 
'rithmetic is done on *must be COMP-5* (native binary). It's an address. You 
don't want to truncate an address if it happens to be "higher" than 999,999,999.

If control info is needed I'd look to keep it in a separate area, "linked" to 
the allocated memory by the address of the allocated memory.

On the COMP-5 vs COMP (or BINARY, I've got into the habit of using (mostly)) I 
didn't get any feedback after my suggestion so I was wondering...

COMP with nine digits can, at least prior to V5, can have performance issues 
(see the Tuning Guides). I've not checked, but I think that it is now less of a 
problem, or no problem, due to the new compiler. Perhaps remains a problem at 
some level of OPT, I don't know.

On Tuesday, 9 August 2016 17:34:15 UTC+2, Frank Swarbrick  wrote:
> Bill, you got me on that one.  Open for suggestions.  I could simply do 
> pointer arithmetic, but this way worked so I went with it.  If I separated 
> the control area and still only pass the address of the table area back to 
> the client, how do you suggest I "anchor" it?
> 
> 
> Use of UNBOUNDED to make it more explicit that there is no particular maximum 
> number of rows.
> 
> 
> I used COMP with TRUNC(OPT).  Aren't you one who said that COMP with 
> TRUNC(OPT) performs better than COMP-5?
> 
> 
> Thanks,
> 
> Frank
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bill Woodger 
> Sent: Monday, August 8, 2016 6:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Enterprise COBOL API for dynamic capacity tables
> 
> "leftmost-character-position
> 
> Must be an arithmetic expression. The evaluation of 
> leftmost-character-position must result in a positive nonzero integer that is 
> less than or equal to the number of characters in the data item referenced by 
> data-name-1."
> 
> So, you are using undefined behaviour (and non-Standard at that).
> 
> IBM have now allowed zero to be valid for leftmost-character-position (again 
> non-Standard, although I don't think it is listed as an IBM Extension). 
> Negative reference-modification? No.
> 
> Of course, it is like a zero/negative subscript. Until someone comes along 
> and changes the compiler, that is not allowed, but it is known exactly how it 
> operates.
> 
> However, if IBM do change the compiler - what then?
> 
> I'd either look to use a separate control-area, come up with a more secure 
> way of referencing an "attached" one, or remove the need for a control-area.
> 
> Out of interest, why COMP not COMP-5?
> 
> Do you feel there is a benefit to using UNBOUNDED over a plain ODO? After 
> all, UNBOUNDED is an IBM Extension to allow for dynamically-sized tables 
> (although not *those* dynamically-sized tables). It's tough to say then that 
> "IBM doesn't allow it".
> 
> --
> 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: How does COBOL detect a recursive call?

[Hardee, Chuck]

Okay, let's run with this one.

If program A has an entry, B, and the program is compiled with NAME(ALIAS), 
when the program is linked, there will be an entry for A and an entry for B as 
an ALIAS of A.

When A is executed, a statement in the program says SET  TO ENTRY B where 
 is defined as PROCEDURE-POINTER.

Does a separate copy of the load module get loaded as B when this SET statement 
is executed or does the runtime simply gain access to the entry point B within 
the currently loaded version of A?

If a separate copy of the load module is loaded as B, where is the recursion?
If a separate copy of the load module is not loaded, I can see the recursion.

C-

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, August 09, 2016 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does COBOL detect a recursive call?

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/reus.htm
When you link edit, you indicate the re-usability of the program.
When the program runs, it reuses the same program if re-entrant.  Each
use has a different set of registers and working storage.
Serially reusable can be self modifying (storing into load module
areas), but can be reused after completing.  Needs a new copy for a
simultaneous use.
None means the program must be reloaded from disk for every use.

When you run a program, the LOAD macro examines the directory and
loads as appropriate.
http://www.longpelaexpertise.com/ezine/ReentrantBeginners.php



On Tue, Aug 9, 2016 at 9:59 AM, John McKown
 wrote:
> On Tue, Aug 9, 2016 at 9:40 AM, John McKown 
> wrote:
>
>> This is a kind of curiosity question. Unless a COBOL program is compiled
>> with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
>> program cannot CALL itself. I have also found out that if you use an ENTRY
>> statement and the compile NAME(ALIAS), you cannot do a CALL of the alias
>> from the "main" program either. E.g. if you have a PROGRAM-ID. A. and an
>> ENTRY 'B', then you cannot CALL 'B' while running A. I am thinking this
>> must be in some way related to the fact that 'A' and 'B' share the same
>> WORKING-STORAGE area. But I was just wondering if anybody knows how this is
>> implemented. Of course, it is probably likely to change between releases,
>> so it's not something I could depend on.
>>
>> Why the interest? Because while talking with Chuck Hardee about having an
>> LE condition handler in the same source member (as an ENTRY) as the main
>> COBOL routine, we found that the run-unit will abend with a U4087-2 and
>> some messages about recursive invocation. So as a test, I compiled a sample
>> which got the U4087-2 with the THREAD option and RECURSIVE clause, and that
>> ran successfully. However the THREAD option comes with some possibley nasty
>> side restrictions. In particular, no INITIAL clause in the PROGRAM-ID
>> sentence and, worse, no use of SORT / MERGE verbs.
>>
>
> Well, here I am talking to myself again. At least I'm not, yet, into the 3
> way arguments with myself. But it turns out that I misread the manual.
> RECURSIVE is required on the PROGRAM-ID if THREAD is used, but not vice
> versa. So it appears that all I really need is the RECURSIVE clause on the
> PROGRAM-ID and not the THREAD compile option. But I'm still mildly curious
> about how COBOL detects recursion, if you know off-hand.
>
> --
> Klein bottle for rent -- inquire within.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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: How does COBOL detect a recursive call?

[Mike Schwab]

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/reus.htm
When you link edit, you indicate the re-usability of the program.
When the program runs, it reuses the same program if re-entrant.  Each
use has a different set of registers and working storage.
Serially reusable can be self modifying (storing into load module
areas), but can be reused after completing.  Needs a new copy for a
simultaneous use.
None means the program must be reloaded from disk for every use.

When you run a program, the LOAD macro examines the directory and
loads as appropriate.
http://www.longpelaexpertise.com/ezine/ReentrantBeginners.php



On Tue, Aug 9, 2016 at 9:59 AM, John McKown
 wrote:
> On Tue, Aug 9, 2016 at 9:40 AM, John McKown 
> wrote:
>
>> This is a kind of curiosity question. Unless a COBOL program is compiled
>> with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
>> program cannot CALL itself. I have also found out that if you use an ENTRY
>> statement and the compile NAME(ALIAS), you cannot do a CALL of the alias
>> from the "main" program either. E.g. if you have a PROGRAM-ID. A. and an
>> ENTRY 'B', then you cannot CALL 'B' while running A. I am thinking this
>> must be in some way related to the fact that 'A' and 'B' share the same
>> WORKING-STORAGE area. But I was just wondering if anybody knows how this is
>> implemented. Of course, it is probably likely to change between releases,
>> so it's not something I could depend on.
>>
>> Why the interest? Because while talking with Chuck Hardee about having an
>> LE condition handler in the same source member (as an ENTRY) as the main
>> COBOL routine, we found that the run-unit will abend with a U4087-2 and
>> some messages about recursive invocation. So as a test, I compiled a sample
>> which got the U4087-2 with the THREAD option and RECURSIVE clause, and that
>> ran successfully. However the THREAD option comes with some possibley nasty
>> side restrictions. In particular, no INITIAL clause in the PROGRAM-ID
>> sentence and, worse, no use of SORT / MERGE verbs.
>>
>
> Well, here I am talking to myself again. At least I'm not, yet, into the 3
> way arguments with myself. But it turns out that I misread the manual.
> RECURSIVE is required on the PROGRAM-ID if THREAD is used, but not vice
> versa. So it appears that all I really need is the RECURSIVE clause on the
> PROGRAM-ID and not the THREAD compile option. But I'm still mildly curious
> about how COBOL detects recursion, if you know off-hand.
>
> --
> Klein bottle for rent -- inquire within.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

How does COBOL detect a recursive call?

[Bill Woodger]

Conceptually, it sets a flag at the start of execution, and resets it when the 
GOBACK (or other way to get out of a program) is processed.

Prior to setting the flag it tests to see if it is still (already) set. If so, 
the program has been entered recursively, either directly or by CALLing (or 
otherwise transferring control to) a program which in turn CALLs the original.

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

Re: Enterprise COBOL API for dynamic capacity tables

[John McKown]

On Tue, Aug 9, 2016 at 10:56 AM, David Crayford  wrote:

> On 9/08/2016 11:49 PM, John McKown wrote:
>
>> On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
>> frank.swarbr...@outlook.com> wrote:
>>
>> Since I developed it at work for work I'll have to ask my employer about
>>> that.  Of course perhaps I should have asked before posting it publicly,
>>> but that's water under the bridge now!
>>>
>>> Sidetracking, has anyone used GitHub for z/OS production source
>>> repository.  Meaning interacting with it directly from the mainframe?
>>> All
>>> of our distributed development groups use it, and it might be nice if we
>>> could use it as well.
>>>
>>> ​Just as a personal observation, I'd think that this would be difficult.
>> Someone would need to port the "git" command to z/OS. And that would
>> likely
>> be a major undertaking since it uses the GNU tools to do a lot of it's
>> setup. It may also depend on some gcc (GNU compiler) specific
>> functionality. And, even if it is ported, there is the historic ASCII (UTF
>> actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
>> I've read about due to the Windows CRLF vs UNIX LF-only line ending
>> causing
>> "problems".​
>>
>>
> I use git for z/OS UNIX stuff via SMB and it works well from a PC shell. A
> script that mirrors PDS libraries should work.
>

​Ah, I hadn't thought about using the Linux or Windows version of git &
z/OS NFS to map the z/OS data onto a PC. Interesting!​



-- 
Klein bottle for rent -- inquire within.

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: Delta Outage

[Gerhard Adam]

Apparently there are 500 servers involved.  I have my own speculations as to
why they didn't declare a disaster.

As a result, the outage was extended because it appears to be taking them in
excess of 12 hours to reboot everything.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, August 9, 2016 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delta Outage

Then WHY did they not initiate their DR and move all systems to the HOT
Site.  I just finished putting in a System that has a RTO=RPO=0 

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Tuesday, August 9, 2016 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delta Outage

>From what I understand, it isn't a simple power outage, but rather a fire in
the data center.

http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
airlines/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, August 9, 2016 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delta Outage

I live in Texas and we have ERCOT, and Texas produces more wind energy than
3 countries.  And Texas has NO Interconnects To other grids.  

It its reprehensible that Delta does not have enough battery power and
gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
unless there is a major storm in that area does not lose power  

--
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: Enterprise COBOL API for dynamic capacity tables

[David Crayford]

On 9/08/2016 11:49 PM, John McKown wrote:

On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:


Since I developed it at work for work I'll have to ask my employer about
that.  Of course perhaps I should have asked before posting it publicly,
but that's water under the bridge now!

Sidetracking, has anyone used GitHub for z/OS production source
repository.  Meaning interacting with it directly from the mainframe?  All
of our distributed development groups use it, and it might be nice if we
could use it as well.


​Just as a personal observation, I'd think that this would be difficult.
Someone would need to port the "git" command to z/OS. And that would likely
be a major undertaking since it uses the GNU tools to do a lot of it's
setup. It may also depend on some gcc (GNU compiler) specific
functionality. And, even if it is ported, there is the historic ASCII (UTF
actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
I've read about due to the Windows CRLF vs UNIX LF-only line ending causing
"problems".​



I use git for z/OS UNIX stuff via SMB and it works well from a PC shell. 
A script that mirrors PDS libraries should work.





Frank




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

Re: Enterprise COBOL API for dynamic capacity tables

[John McKown]

On Tue, Aug 9, 2016 at 10:40 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Since I developed it at work for work I'll have to ask my employer about
> that.  Of course perhaps I should have asked before posting it publicly,
> but that's water under the bridge now!
>
> Sidetracking, has anyone used GitHub for z/OS production source
> repository.  Meaning interacting with it directly from the mainframe?  All
> of our distributed development groups use it, and it might be nice if we
> could use it as well.
>

​Just as a personal observation, I'd think that this would be difficult.
Someone would need to port the "git" command to z/OS. And that would likely
be a major undertaking since it uses the GNU tools to do a lot of it's
setup. It may also depend on some gcc (GNU compiler) specific
functionality. And, even if it is ported, there is the historic ASCII (UTF
actually) vs EBCDIC dilemma. You wouldn't believe the number of problems
I've read about due to the Windows CRLF vs UNIX LF-only line ending causing
"problems".​



>
> Frank
>
>

-- 
Klein bottle for rent -- inquire within.

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: COBOL 2014 dynamic capacity tables

[David Crayford]

On 9/08/2016 11:42 PM, Frank Swarbrick wrote:

Neither here nor there, but I did not know that C++ enums could have 
non-numeric values!  Are they limited to a single character?  Just wondering...


With C/C++ anything in single quotes is a char which equates to an 
integer. You cannot switch() on strings as it makes no sense as a switch 
is a branch table. Having said that, C#

supports switch on strings but that's syntactic sugar, but very nice.



From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Monday, August 8, 2016 9:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

On 9/08/2016 12:36 AM, Farley, Peter x23353 wrote:

David,

Not so easy to write as you might think.  The COBOL LE environment and the 
C/C++ LE environment are very different.  Calling C/C++ runtime routines (other 
than the Metal C ones resident in the system, but even some of those require 
some memory-allocation initialization) requires that the C/C++ RTL environment 
be set up, but you do not want to do that for every call, so you have to have 
at least a name/token pair to save the (created once) C/C++ environment.

#pragma linkage(...,fetchable) takes care of the ILC linkage. LE will
dynamically load the C++ module and use the same LE environment for both
the COBOL and the C++ program. I've done this before for ILC calls
between HLASM->C++ and it works well. It's very fast, the call overhead
is just a few instructions in the FECB glue code.

I wrote a test with a COBOL main that calls a C++ subroutine 10,000,000
times. It ran in 01.33 CPU seconds, roughly the same as C++ calling a
statically linked C++ routine.

 identification division.

 program-id.  cobilc.

 data division.

 working-storage section.

 01  set-module-name  pic x(08) value "PCOLSET ".

 procedure division.

 perform 1000 times
 call set-module-name
 end-perform

 goback.

#pragma linkage(PCOLSET,fetchable)

extern "C" int PCOLSET()
{
  return 0;
}

HTRT01I CPU (Total) Elapsed
CPU (TCB)CPU (SRB) Service
HTRT02I Jobname  Stepname ProcStepRCI/O hh:mm:ss.th hh:mm:ss.th
hh:mm:ss.th  hh:mm:ss.th Units
HTRT03I COBILC   C00 73   01.33 02.24
01.3300.00 29549


And probably impossible for any RTL routine that requires POSIX ON, though I 
don't suppose the data collection routines fall into that category.

One of my colleagues wrote a POSIX(ON) COBOL program a few weeks ago. It
uses the new callable services for HTTP web services and POSIX(ON) is a
requirement. No problems.


I investigated this once upon a time and decided that with the amount of work 
required, it would probably be better to wait for IBM to provide it.  Maybe 
COBOL V6++ will do that.  :)

  From what I can tell it would be quite easy. It's simple to write a C++
module to wrap an STL container. I would design it to take one argument,
a COBOL record (C struct) list with a request type, the set handle and a
record buffer. For example, for a dictionary (std::set)  NEW, TERM,
INSERT, FIND, REPLACE, DELETE etc. I would store records in the set as
C++ strings to simplify memory management and write a custom comparator
function for comparing keys. One constraint would be that record keys
must be fixed length, but this is COBOL right so that's nothing new.

Excuse my COBOL, it's been a while but something like this which would
have a C/C++ structure mapping in the API.

01 stl-set.
 05 stl-set-token   pic x(4) value low-values.
 05 stl-set-method  pic x.
88 stl-set-method-new value 'N'.
88 stl-set-method-insert  value 'I'.
88 stl-set-method-findvalue 'F'.
88 stl-set-method-update  value 'U'.
88 stl-set-method-delete  value 'D'.
88 stl-set-method-termvalue 'T'.
 05 stl-set-key-length  pic 9(8) binary.
 05 stl-set-rec-length  pic 9(8) binary.
 05 stl-set-rec-ptr pointer.

struct stl_set
{
  void * token;// ptr to std::set instance
  enum // request type
  {
method_new= 'N',   // - create a new set
method_insert = 'I',   // - insert a record
method_find   = 'F',   // - find a record
method_update = 'U',   // - update a record
method_delete = 'D',   // - delete a record
method_term   = 'T'// - destroy the set
  } method;
  size_t keylen;   // [input]  the fixed key length
  size_t reclen;   // [in/out] the record length
  void * rec;  // [in/out] the record buffer
}


Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Monday, August 08, 2016 7:49 AM
To: 

Re: COBOL 2014 dynamic capacity tables

[Frank Swarbrick]

Neither here nor there, but I did not know that C++ enums could have 
non-numeric values!  Are they limited to a single character?  Just wondering...


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Monday, August 8, 2016 9:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

On 9/08/2016 12:36 AM, Farley, Peter x23353 wrote:
> David,
>
> Not so easy to write as you might think.  The COBOL LE environment and the 
> C/C++ LE environment are very different.  Calling C/C++ runtime routines 
> (other than the Metal C ones resident in the system, but even some of those 
> require some memory-allocation initialization) requires that the C/C++ RTL 
> environment be set up, but you do not want to do that for every call, so you 
> have to have at least a name/token pair to save the (created once) C/C++ 
> environment.

#pragma linkage(...,fetchable) takes care of the ILC linkage. LE will
dynamically load the C++ module and use the same LE environment for both
the COBOL and the C++ program. I've done this before for ILC calls
between HLASM->C++ and it works well. It's very fast, the call overhead
is just a few instructions in the FECB glue code.

I wrote a test with a COBOL main that calls a C++ subroutine 10,000,000
times. It ran in 01.33 CPU seconds, roughly the same as C++ calling a
statically linked C++ routine.

identification division.

program-id.  cobilc.

data division.

working-storage section.

01  set-module-name  pic x(08) value "PCOLSET ".

procedure division.

perform 1000 times
call set-module-name
end-perform

goback.

#pragma linkage(PCOLSET,fetchable)

extern "C" int PCOLSET()
{
 return 0;
}

HTRT01I CPU (Total) Elapsed
CPU (TCB)CPU (SRB) Service
HTRT02I Jobname  Stepname ProcStepRCI/O hh:mm:ss.th hh:mm:ss.th
hh:mm:ss.th  hh:mm:ss.th Units
HTRT03I COBILC   C00 73   01.33 02.24
01.3300.00 29549

> And probably impossible for any RTL routine that requires POSIX ON, though I 
> don't suppose the data collection routines fall into that category.

One of my colleagues wrote a POSIX(ON) COBOL program a few weeks ago. It
uses the new callable services for HTTP web services and POSIX(ON) is a
requirement. No problems.

> I investigated this once upon a time and decided that with the amount of work 
> required, it would probably be better to wait for IBM to provide it.  Maybe 
> COBOL V6++ will do that.  :)

 From what I can tell it would be quite easy. It's simple to write a C++
module to wrap an STL container. I would design it to take one argument,
a COBOL record (C struct) list with a request type, the set handle and a
record buffer. For example, for a dictionary (std::set)  NEW, TERM,
INSERT, FIND, REPLACE, DELETE etc. I would store records in the set as
C++ strings to simplify memory management and write a custom comparator
function for comparing keys. One constraint would be that record keys
must be fixed length, but this is COBOL right so that's nothing new.

Excuse my COBOL, it's been a while but something like this which would
have a C/C++ structure mapping in the API.

01 stl-set.
05 stl-set-token   pic x(4) value low-values.
05 stl-set-method  pic x.
   88 stl-set-method-new value 'N'.
   88 stl-set-method-insert  value 'I'.
   88 stl-set-method-findvalue 'F'.
   88 stl-set-method-update  value 'U'.
   88 stl-set-method-delete  value 'D'.
   88 stl-set-method-termvalue 'T'.
05 stl-set-key-length  pic 9(8) binary.
05 stl-set-rec-length  pic 9(8) binary.
05 stl-set-rec-ptr pointer.

struct stl_set
{
 void * token;// ptr to std::set instance
 enum // request type
 {
   method_new= 'N',   // - create a new set
   method_insert = 'I',   // - insert a record
   method_find   = 'F',   // - find a record
   method_update = 'U',   // - update a record
   method_delete = 'D',   // - delete a record
   method_term   = 'T'// - destroy the set
 } method;
 size_t keylen;   // [input]  the fixed key length
 size_t reclen;   // [in/out] the record length
 void * rec;  // [in/out] the record buffer
}

> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David Crayford
> Sent: Monday, August 08, 2016 7:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 2014 dynamic capacity tables
>
> On 5/08/2016 11:11 PM, Frank Swarbrick wrote:
>> That's good to know.  I searched the internet and found a page about 
>> implementing dynamic arrays in C and he was using "double", but 1.5 also 
>> sounds reasonable.  I wonder 

Re: Delta Outage

[Steve Beaver]

Then WHY did they not initiate their DR and move all systems to the HOT
Site.  I just finished putting in a 
System that has a RTO=RPO=0 

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Tuesday, August 9, 2016 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delta Outage

>From what I understand, it isn't a simple power outage, but rather a fire in
the data center.

http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
airlines/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, August 9, 2016 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delta Outage

I live in Texas and we have ERCOT, and Texas produces more wind energy than
3 countries.  And Texas has NO Interconnects To other grids.  

It its reprehensible that Delta does not have enough battery power and
gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
unless there is a major storm in that area does not lose power  

--
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: Enterprise COBOL API for dynamic capacity tables

[Frank Swarbrick]

Since I developed it at work for work I'll have to ask my employer about that.  
Of course perhaps I should have asked before posting it publicly, but that's 
water under the bridge now!


Sidetracking, has anyone used GitHub for z/OS production source repository.  
Meaning interacting with it directly from the mainframe?  All of our 
distributed development groups use it, and it might be nice if we could use it 
as well.


Frank


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Monday, August 8, 2016 7:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL API for dynamic capacity tables

On Mon, Aug 8, 2016 at 6:46 PM, Frank Swarbrick  wrote:

> It's always something, ain't it!
>
> Check it out now.
>
> Frank
>

That looked very interesting. I divided up the integrated copybooks into
separate files. I've also placed them in a local git repository (git is a
source code management tool used by a number of FOSS projects, especially
the Linux kernel)
. One thing, which is quite important to me, is that there is no LICENSE
information, nor any copyright asserted in the source code. This would mean
that the code _IS_ copyright under the normal Berne Convention (
https://en.wikipedia.org/wiki/Berne_Convention). Basically, this means
[https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Berne_Convention_signatories.svg/335px-Berne_Convention_signatories.svg.png]

Berne Convention - Wikipedia, the free 
encyclopedia
en.wikipedia.org
Content. The Berne Convention requires its signatories to treat the copyright 
of works of authors from other signatory countries (known as members of the 
Berne Union ...


"fair use" (https://en.wikipedia.org/wiki/Fair_use). This is actually quite
restrictive since, at least theoretically,


one could not integrate the code into a larger work. If the larger work is
not "distributed" (which has even more legal meanings), then all is well.
But if, for instance. I were to use it in a utility program, I could not
legally put such a program into the CBTtape.org site because that could
possibly result in legal action. Since the copyright is 50 years from time
of death, your heirs could sue for copyright infringement. Yes, this is
very theoretical, but it is one of my "hot buttons" as a FOSS advocate.
Would you mind putting up a LICENSE document? If you want to say "use as
you will", then you might want to use the "BSD 2 clause" license (basically
- somebody couldn't claim it as their own & must include your copyright of
the code in their distribution, if distributed). There are a lot of FOSS
licenses you could choose from (I recommend against GPL or AGPL since this
is a very small amount of code). The most free license it to release it
into the PUBLIC DOMAIN. I.e. "Here it is. Use it as you will. But don't
bother me about it."

If you put in under a FOSS license, I would love to place it on GitHub. I
have a few things of mine there, https://github.com/JohnArchieMcKown .


--
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

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

Re: Enterprise COBOL API for dynamic capacity tables

[Frank Swarbrick]

Bill, you got me on that one.  Open for suggestions.  I could simply do pointer 
arithmetic, but this way worked so I went with it.  If I separated the control 
area and still only pass the address of the table area back to the client, how 
do you suggest I "anchor" it?


Use of UNBOUNDED to make it more explicit that there is no particular maximum 
number of rows.


I used COMP with TRUNC(OPT).  Aren't you one who said that COMP with TRUNC(OPT) 
performs better than COMP-5?


Thanks,

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Monday, August 8, 2016 6:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Enterprise COBOL API for dynamic capacity tables

"leftmost-character-position

Must be an arithmetic expression. The evaluation of leftmost-character-position 
must result in a positive nonzero integer that is less than or equal to the 
number of characters in the data item referenced by data-name-1."

So, you are using undefined behaviour (and non-Standard at that).

IBM have now allowed zero to be valid for leftmost-character-position (again 
non-Standard, although I don't think it is listed as an IBM Extension). 
Negative reference-modification? No.

Of course, it is like a zero/negative subscript. Until someone comes along and 
changes the compiler, that is not allowed, but it is known exactly how it 
operates.

However, if IBM do change the compiler - what then?

I'd either look to use a separate control-area, come up with a more secure way 
of referencing an "attached" one, or remove the need for a control-area.

Out of interest, why COMP not COMP-5?

Do you feel there is a benefit to using UNBOUNDED over a plain ODO? After all, 
UNBOUNDED is an IBM Extension to allow for dynamically-sized tables (although 
not *those* dynamically-sized tables). It's tough to say then that "IBM doesn't 
allow it".

--
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: Delta Outage

[Gerhard Adam]

>From what I understand, it isn't a simple power outage, but rather a fire in
the data center.

http://arstechnica.com/business/2016/08/data-center-disaster-disrupts-delta-
airlines/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, August 9, 2016 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delta Outage

I live in Texas and we have ERCOT, and Texas produces more wind energy than
3 countries.  And Texas has NO Interconnects To other grids.  

It its reprehensible that Delta does not have enough battery power and
gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
unless there is a major storm in that area does not lose power  

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

Delta Outage

[Steve Beaver]

I live in Texas and we have ERCOT, and Texas produces more wind energy than
3 countries.  And Texas has NO Interconnects
To other grids.  

It its reprehensible that Delta does not have enough battery power and
gen-sets to cover the screw-ups by Atlanta Power. AA is in  Irving and
unless there is a major storm in that area does not lose power  

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

Re: SHARE Atlanta proceedings

[Chris Hoelscher]

Of course Obama would have no impact:

If you like your conference, you can keep your conference ... 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, August 09, 2016 10:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] SHARE Atlanta proceedings
> 
> The problem started early Monday morning in Atlanta, Delta's world-wide
> headquarters. I imagine that most SHARE attendees had blown town by
> then. It's been widely reported as a 'power failure', but there's a public
> squabble over whether the glitch occurred within Georgia Power's grid or
> within Delta's own internal power distribution network. As Ed says, the truth
> will eventually come out.
> 
> It's reported that the problem was exacerbated by Delta's recent pullback
> from inter-airline mutual bailout agreements. This reduced Delta's ability to
> rebook passengers on other carriers. The most public retrenchment involved
> American Airlines, whom Delta accused of benefitting from the agreement
> far more than Delta did. The message: Delta is so good that AA was more of a
> millstone than an ally. Maybe good, but not perfect.
> 
> I fly Southwest, which had its own computer problems a couple of weeks
> earlier. SHARE managed to find a sweet spot in between the two airline
> FUBARs. Even Obama's Monday visit to Atlanta--literally across the street
> from the Marriott--seemed to have minimal impact on the conference.
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Edward Finnell
> Sent: Tuesday, August 09, 2016 12:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: SHARE Atlanta proceedings
> 
> Right. The news has been slow dribbling out. My nephew is a sysprog in
> Atlanta(not for Delta) but several of the neighbors are. We'll get the scoop
> eventually.
> 
> 
> In a message dated 8/9/2016 1:12:34 A.M. Central Daylight Time,
> 0107ca423a92-dmarc-requ...@listserv.ua.edu writes:
> 
> I think  the problems started on  Sunday?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: How does COBOL detect a recursive call?

[John McKown]

On Tue, Aug 9, 2016 at 9:40 AM, John McKown 
wrote:

> This is a kind of curiosity question. Unless a COBOL program is compiled
> with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
> program cannot CALL itself. I have also found out that if you use an ENTRY
> statement and the compile NAME(ALIAS), you cannot do a CALL of the alias
> from the "main" program either. E.g. if you have a PROGRAM-ID. A. and an
> ENTRY 'B', then you cannot CALL 'B' while running A. I am thinking this
> must be in some way related to the fact that 'A' and 'B' share the same
> WORKING-STORAGE area. But I was just wondering if anybody knows how this is
> implemented. Of course, it is probably likely to change between releases,
> so it's not something I could depend on.
>
> Why the interest? Because while talking with Chuck Hardee about having an
> LE condition handler in the same source member (as an ENTRY) as the main
> COBOL routine, we found that the run-unit will abend with a U4087-2 and
> some messages about recursive invocation. So as a test, I compiled a sample
> which got the U4087-2 with the THREAD option and RECURSIVE clause, and that
> ran successfully. However the THREAD option comes with some possibley nasty
> side restrictions. In particular, no INITIAL clause in the PROGRAM-ID
> sentence and, worse, no use of SORT / MERGE verbs.
>

​Well, here I am talking to myself again. At least I'm not, yet, into the 3
way arguments with myself. But it turns out that I misread the manual.
RECURSIVE is required on the PROGRAM-ID if THREAD is used, but not vice
versa. So it appears that all I really need is the RECURSIVE clause on the
PROGRAM-ID and not the THREAD compile option. But I'm still mildly curious
about how COBOL detects recursion, if you know off-hand.​

-- 
Klein bottle for rent -- inquire within.

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: SHARE Atlanta proceedings

[william janulin]

Where were the backup generators? Do they even have them?
 

On Tuesday, August 9, 2016 10:47 AM, Jesse 1 Robinson 
 wrote:
 

 The problem started early Monday morning in Atlanta, Delta's world-wide 
headquarters. I imagine that most SHARE attendees had blown town by then. It's 
been widely reported as a 'power failure', but there's a public squabble over 
whether the glitch occurred within Georgia Power's grid or within Delta's own 
internal power distribution network. As Ed says, the truth will eventually come 
out. 

It's reported that the problem was exacerbated by Delta's recent pullback from 
inter-airline mutual bailout agreements. This reduced Delta's ability to rebook 
passengers on other carriers. The most public retrenchment involved American 
Airlines, whom Delta accused of benefitting from the agreement far more than 
Delta did. The message: Delta is so good that AA was more of a millstone than 
an ally. Maybe good, but not perfect.

I fly Southwest, which had its own computer problems a couple of weeks earlier. 
SHARE managed to find a sweet spot in between the two airline FUBARs. Even 
Obama's Monday visit to Atlanta--literally across the street from the 
Marriott--seemed to have minimal impact on the conference. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, August 09, 2016 12:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SHARE Atlanta proceedings

Right. The news has been slow dribbling out. My nephew is a sysprog in 
Atlanta(not for Delta) but several of the neighbors are. We'll get the scoop 
eventually.
 
 
In a message dated 8/9/2016 1:12:34 A.M. Central Daylight Time, 
0107ca423a92-dmarc-requ...@listserv.ua.edu writes:

I think  the problems started on  Sunday?

--
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: SHARE Atlanta proceedings

[Jesse 1 Robinson]

The problem started early Monday morning in Atlanta, Delta's world-wide 
headquarters. I imagine that most SHARE attendees had blown town by then. It's 
been widely reported as a 'power failure', but there's a public squabble over 
whether the glitch occurred within Georgia Power's grid or within Delta's own 
internal power distribution network. As Ed says, the truth will eventually come 
out. 

It's reported that the problem was exacerbated by Delta's recent pullback from 
inter-airline mutual bailout agreements. This reduced Delta's ability to rebook 
passengers on other carriers. The most public retrenchment involved American 
Airlines, whom Delta accused of benefitting from the agreement far more than 
Delta did. The message: Delta is so good that AA was more of a millstone than 
an ally. Maybe good, but not perfect.

I fly Southwest, which had its own computer problems a couple of weeks earlier. 
SHARE managed to find a sweet spot in between the two airline FUBARs. Even 
Obama's Monday visit to Atlanta--literally across the street from the 
Marriott--seemed to have minimal impact on the conference. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, August 09, 2016 12:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SHARE Atlanta proceedings

Right. The news has been slow dribbling out. My nephew is a sysprog in 
Atlanta(not for Delta) but several of the neighbors are. We'll get the scoop 
eventually.
 
 
In a message dated 8/9/2016 1:12:34 A.M. Central Daylight Time, 
0107ca423a92-dmarc-requ...@listserv.ua.edu writes:

I think  the problems started on  Sunday?

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

How does COBOL detect a recursive call?

[John McKown]

This is a kind of curiosity question. Unless a COBOL program is compiled
with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
program cannot CALL itself. I have also found out that if you use an ENTRY
statement and the compile NAME(ALIAS), you cannot do a CALL of the alias
from the "main" program either. E.g. if you have a PROGRAM-ID. A. and an
ENTRY 'B', then you cannot CALL 'B' while running A. I am thinking this
must be in some way related to the fact that 'A' and 'B' share the same
WORKING-STORAGE area. But I was just wondering if anybody knows how this is
implemented. Of course, it is probably likely to change between releases,
so it's not something I could depend on.

Why the interest? Because while talking with Chuck Hardee about having an
LE condition handler in the same source member (as an ENTRY) as the main
COBOL routine, we found that the run-unit will abend with a U4087-2 and
some messages about recursive invocation. So as a test, I compiled a sample
which got the U4087-2 with the THREAD option and RECURSIVE clause, and that
ran successfully. However the THREAD option comes with some possibley nasty
side restrictions. In particular, no INITIAL clause in the PROGRAM-ID
sentence and, worse, no use of SORT / MERGE verbs.

-- 
Klein bottle for rent -- inquire within.

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: AW: COBOL 2014 dynamic capacity tables

[David Crayford]

Cool! So you run the heap control blocks and take snapshots? Does that 
work well when lots of memory is being allocated?



On 9/08/2016 9:16 PM, bernd.oppol...@t-online.de wrote:

No, I don't instrument at all.

I use my knowledge of the LE heap implementation (see the presentation
mentioned below) to store a map of all allocated and free areas at a given time
(area adresses and lengths) and then - some microseconds later - I compare that
with the new image then. Then I build a delta listing which shows all the areas
that have changed in the meantime, that is, which have been allocated and not 
freed.

If you call this before and after a critical function, you will see exactly
what areas are left "unfreed" by this function. This proved to be very
helpful in our environment, especially if the critical function is written
by another team. (I don't need to "instrument" the functions of the foreign 
team).

Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: COBOL 2014 dynamic capacity tables
Datum: 2016-08-09T13:53:15+0200
Von: "David Crayford" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

I  use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory
leaks. How is your instrumentation different? I assume you wrap
malloc()/free() calls?


On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:

IMO there is no need to create additional heaps
to support dynamic tables in COBOL.

I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something like "Stacks are easy,
heaps are fun"). There are COBOL examples included, which
use the LE functions CEEGTST (get storage) and CEEFRST
(free storage) - I hope, I recall the names correctly.

Based on these functions (which are malloc and free, after all),
you could do all sorts of dynamic allocations from COBOL, using
the normal LE "user heap", which is sufficient, IMO.

BTW: I wrote some functions in the last few days, which dumps all
the allocated heap areas and - more interesting - they write reports,
how the heap has changed since the last call. This is very interesting
...
if you have a function that you think that does not free its heap areas
properly, you can call this heap report function before and after
this function call and find out by looking at the so called heap delta
listing.

If you are interested, feel free to contact me offline.

Kind regards

Bernd





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

AW: COBOL 2014 dynamic capacity tables

[bernd.oppol...@t-online.de]

No, I don't instrument at all. 

I use my knowledge of the LE heap implementation (see the presentation
mentioned below) to store a map of all allocated and free areas at a given time
(area adresses and lengths) and then - some microseconds later - I compare that 
with the new image then. Then I build a delta listing which shows all the areas
that have changed in the meantime, that is, which have been allocated and not 
freed. 

If you call this before and after a critical function, you will see exactly
what areas are left "unfreed" by this function. This proved to be very 
helpful in our environment, especially if the critical function is written 
by another team. (I don't need to "instrument" the functions of the foreign 
team). 

Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: COBOL 2014 dynamic capacity tables
Datum: 2016-08-09T13:53:15+0200
Von: "David Crayford" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

I  use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory 
leaks. How is your instrumentation different? I assume you wrap 
malloc()/free() calls?


On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:
> IMO there is no need to create additional heaps
> to support dynamic tables in COBOL.
>
> I did some research some days ago on the LE heap
> implementation and found an old IBM presentation (from 2005) on
> this topic called "Stacks and Heaps" (you will find it using
> Google, the full title reads something like "Stacks are easy,
> heaps are fun"). There are COBOL examples included, which
> use the LE functions CEEGTST (get storage) and CEEFRST
> (free storage) - I hope, I recall the names correctly.
>
> Based on these functions (which are malloc and free, after all),
> you could do all sorts of dynamic allocations from COBOL, using
> the normal LE "user heap", which is sufficient, IMO.
>
> BTW: I wrote some functions in the last few days, which dumps all
> the allocated heap areas and - more interesting - they write reports,
> how the heap has changed since the last call. This is very interesting 
> ...
> if you have a function that you think that does not free its heap areas
> properly, you can call this heap report function before and after
> this function call and find out by looking at the so called heap delta 
> listing.
>
> If you are interested, feel free to contact me offline.
>
> Kind regards
>
> Bernd
>
>


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

Re: SHARE Atlanta proceedings

[Richards, Robert B.]

Skip,

While I was aware of that link, the look and feel this time around was 
different enough that I thought there might have been a content/path change. I 
downloaded quite a few yesterday, one at a time. Once I have reviewed those, 
I'll check back on that link.

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, August 08, 2016 7:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SHARE Atlanta proceedings

Proceedings eventually end up on this page:

http://www.share.org/page/proceedings

Atlanta is not there yet. I don't know the expected 'drop' date, but it should 
not be too far off. I downloaded a couple of PDFs today by going through the 
SHARE app. Again, it's one by one, but for something you really want in a 
hurry, it's an option. I was in a hurry. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Monday, August 08, 2016 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SHARE Atlanta proceedings

They are available from the Atlanta event page. Try this link:

http://www.share.org/atlanta-agenda

HTH

Mike


On 8 August 2016 at 15:39, Richards, Robert B. 
wrote:

> Does anyone know when the Atlanta SHARE Conference proceedings from 
> last week will be available?
>
> Bob
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
Mike Shorkend
m...@shorkend.com
http://hybrid-web.global.blackspider.com/urlwrap/?q=AXicE2RmqN3EwOC5n4GhKKfSwDJdr7ioTC83MTMnOT-vpCg_Ry85P5eh1NzCz8_Rw8PA0NzI3JAhKD8ptahELygzOSOxKKXYwT_AV8_dP4who6SkwEpfv7y8XK84I78oOzUvBaydgeHhLgYGAAzQIiE
Tel: +972524208743
Fax: +97239772196


--
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 2014 dynamic capacity tables

[David Crayford]

I  use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory 
leaks. How is your instrumentation different? I assume you wrap 
malloc()/free() calls?



On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:

IMO there is no need to create additional heaps
to support dynamic tables in COBOL.

I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something like "Stacks are easy,
heaps are fun"). There are COBOL examples included, which
use the LE functions CEEGTST (get storage) and CEEFRST
(free storage) - I hope, I recall the names correctly.

Based on these functions (which are malloc and free, after all),
you could do all sorts of dynamic allocations from COBOL, using
the normal LE "user heap", which is sufficient, IMO.

BTW: I wrote some functions in the last few days, which dumps all
the allocated heap areas and - more interesting - they write reports,
how the heap has changed since the last call. This is very interesting 
...

if you have a function that you think that does not free its heap areas
properly, you can call this heap report function before and after
this function call and find out by looking at the so called heap delta 
listing.


If you are interested, feel free to contact me offline.

Kind regards

Bernd



Frank Swarbrick schrieb:
By "heap pool" are you referring to using CEECRHP to create 
additional LE heaps?  I am doing that upon creation of the first 
"dynamic table" within a program.  (Just using the defaults of 0 for 
each of the CEECRHP parameters at the moment.)  Are you thinking it 
might make sense to use a separate heap for each table?  I have no 
idea what phi is (I took neither Greek nor higher mathematics), but 
I'll take a look at it.


I personally would like COBOL to have most of those "collection 
classes" you refer to.  But I'm not sure how user friendly these ILCs 
wrappers you refer to would be.  Feel free to develop them, though!  
:-)  We don't have access to the C/C++ compiler, and thus I will not 
be playing around with that.


Frank




--
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: SHARE Atlanta proceedings

[Edward Finnell]

Right. The news has been slow dribbling out. My nephew is a sysprog in  
Atlanta(not for Delta) but several of the neighbors are. We'll get the scoop  
eventually.
 
 
In a message dated 8/9/2016 1:12:34 A.M. Central Daylight Time,  
0107ca423a92-dmarc-requ...@listserv.ua.edu writes:

I think  the problems started on  Sunday?


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

Re: SHARE Atlanta proceedings

[Windt, W.K.F. van der (Fred)]

> What was the attendance?
>
> By the hair on your chinny, chin,chin...
>
> http://www.reuters.com/article/us-delta-air-outages-idUSKCN10J0VP

Share ended Friday around noon. I flew home on Saturday and had no problems 
leaving Atlanta. I think the problems started on Sunday?

Fred!

--
ATTENTION:
The information in this e-mail is confidential and only meant for the intended 
recipient. If you are not the intended recipient, don't use or disclose it in 
any way. Please let the sender know and delete the message immediately.
--

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