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

Re: SHARE Atlanta proceedings

[Edward Finnell]

What was the attendance?
 
By the hair on your chinny, chin,chin...
 
http://www.reuters.com/article/us-delta-air-outages-idUSKCN10J0VP
 
 
 
 
In a message dated 8/8/2016 6:23:15 P.M. Central Daylight Time,  
jesse1.robin...@sce.com writes:

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.  


--
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:01 AM, David Crayford wrote:


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. 


It turns out that statically linking the C++ subroutine not only works 
it's faster.


   identification division.

   program-id.  cobilc.

   data division.

   working-storage section.

   01 set-module-namepic x(8) value 'PCOLSET'.

   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.

   procedure division.

   perform 1000 times
   call "PCOLSET" using stl-set
   end-perform

   goback.

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 COBPSET  C00144   00.33 00.86
00.3300.00  7256


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

IBM Redbooks | Everything You Always Wanted to Know about IDCAMS But Were Afraid to Ask

[Edward Gould]

I am afraid to ask even after reading

> 
> http://www.redbooks.ibm.com/redpieces/abstracts/redp5389.html?Open 
> 

--
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 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 if perhaps there should be some sort of ratcheting down as the number of rows gets 
very large.

The C++ runtime library on z/OS is a commercial offering from Dinkumware. 
Interestingly they use phi as the growth factor. A lot of the choices seem to 
be based on the properties of the memory allocator.  Modern allocators, 
including z/OS LE are configurable, so if you plan to use a growth factor of 2 
then you should look into using heap pools.

I have to 

Re: Interesting C library file open mis-diagnosis

[Paul Gilmartin]

On Mon, 8 Aug 2016 14:01:33 -0700, Charles Mills wrote:

>> Was there a job log message, S213-rc identifying the catenand?
>
>15.52.57 JOB01527  IEC141I 
>013-18,IGG0191B,xxPL,PLKED,ASSEMOBJ-0009,1D41,LS050A,  325
>   325 DATASET.NAME(CZAISAUT)
>
>When I spotted that I figured out the problem. But I started out looking at 
>the program (PLINK) listing. When a program says "this is my problem" it ought 
>to know what it's talking about, right?
>   
Nah.  Just look up that IEC141I in M&C that will tell you what the "-0009" 
means,
and try to remember than catenands are numbered starting from 0, not 1 (I think;
how unlike IBM.  And it should really be "+", not "-".)

Actually, it's just their subtle way of telling you that C programs should be 
built
using UNIX facilities, not JCL.

But does anyone know how to cause "make" to direct its program object output
to a PDSE rather than a UNIX directory?

But what I'd like even more is to see that UNIX directory supported as a
catenand in STEPLIB.

And another of my favorites:
user@OS/390.25.00: rexx "say BPXWDYN( 'alloc path(''/tmp/wombat'') msg(2)' 
)"
IKJ56228I PATH /tmp/wombat NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED
-32745

CATALOG?  I suppose the less you know, the easier it is to understand what it 
means.

-- gil

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

Re: Interesting C library file open mis-diagnosis

[Charles Mills]

I guess one answer is that they should not report the member name. The software 
knows or could know the allocation is concatenated. It should just say "I/O 
error on the allocation, somewhere." I/O error on //DD:ASSEMOBJ.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, August 08, 2016 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Interesting C library file open mis-diagnosis

On Mon, Aug 8, 2016 at 4:01 PM, Charles Mills  wrote:

> > Was there a job log message, S213-rc identifying the catenand?
>
> Yes,
>
> 15.52.57 JOB01527  IEC141I 013-18,IGG0191B,xxPL, 
> PLKED,ASSEMOBJ-0009,1D41,LS050A,  325
>325 DATASET.NAME(CZAISAUT)
>
> When I spotted that I figured out the problem. But I started out 
> looking at the program (PLINK) listing. When a program says "this is 
> my problem" it ought to know what it's talking about, right?
>
> Charles
>
>
​I would generally agree with your statement. I will also say that I'd bet that 
the data in the error message came from the results of a RDJFCB, or equivalent, 
service. Unfortunately, this service's handling of concatenated DDs is rather 
poor. Also (I'm fairly sure), when I/O is done against​

​a DD, unless an "EOV exit" (
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/eefsds.htm)
is specified, there is no feedback as to which DSN in the concatenation 
actually had the I/O error. The aforementioned exit does cause this information 
to be fed back, but can be used to know when the program "switches" (goes to 
end-of-data) on one DSN to another to update a counter in the program. The 
program 
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

[Farley, Peter x23353]

The "leftmost-character-position" issue is easily resolved (though also in a 
non-standard way) by using a work pointer redefined as PIC 9(9) COMP-5, then:

01  TABLE-PTR POINTER.
01  TABLE-PTR9 REDEFINES TABLE-PTR PIC 9(9) COMP-5.
. . . .
SET TABLE-PTR TO TABLE-ADDR
COMPUTE TABLE-PTR9 = TABLE-PTR9 - LENGTH OF  + 1
SET ADDRESS OF  TO TABLE-PTR

Good enough, at least until POINTER becomes a 64-bit address.  Although it does 
ASSUME that TABLE-PTR will be 31-bit clean, which AFAIK is true at least for 
all Enterprise COBOL 4.x versions.

And that future maintainers understand POINTER arithmetic.

It would be interesting if "SET  {DOWN | UP} BY 
" got the same result.  AFAIK that is not in the current 
COBOL definitions though, DOWN and UP are only for INDEX variables.

All of these techniques are CAVEAT EMPTOR and YMMV of course.

I agree that "OCCURS 0 to 1 DEPENDING ON . . . " should be good enough not to 
require using UNBOUNDED, which is not supported in COBOL V4.x versions.  
NOSSRANGE of course is also required for that to work.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Monday, August 08, 2016 8:57 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".

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Interesting C library file open mis-diagnosis

[John McKown]

On Mon, Aug 8, 2016 at 4:01 PM, Charles Mills  wrote:

> > Was there a job log message, S213-rc identifying the catenand?
>
> Yes,
>
> 15.52.57 JOB01527  IEC141I 013-18,IGG0191B,xxPL,
> PLKED,ASSEMOBJ-0009,1D41,LS050A,  325
>325 DATASET.NAME(CZAISAUT)
>
> When I spotted that I figured out the problem. But I started out looking
> at the program (PLINK) listing. When a program says "this is my problem" it
> ought to know what it's talking about, right?
>
> Charles
>
>
​I would generally agree with your statement. I will also say that I'd bet
that the data in the error message came from the results of a RDJFCB, or
equivalent, service. Unfortunately, this service's handling of concatenated
DDs is rather poor. Also (I'm fairly sure), when I/O is done against​

​a DD, unless an "EOV exit" (
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/eefsds.htm)
is specified, there is no feedback as to which DSN in the concatenation
actually had the I/O error. The aforementioned exit does cause this
information to be fed back, but can be used to know when the program
"switches" (goes to end-of-data) on one DSN to another to update a counter
in the program. The program could then use a dynamic allocation "return
information" to get all the DSNs in the concatenation and use the relative
counter to get to the one which actually got the error. Note that this is
just a "swag" on my part since I've never actually done it. If someone
knows for sure, I'd appreciate some real world knowledge on this.


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

Enterprise COBOL API for dynamic capacity tables

[Bill Woodger]

"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

Re: Enterprise COBOL API for dynamic capacity tables

[Frank Swarbrick]

It's always something, ain't it!

Check it out now.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Monday, August 8, 2016 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL API for dynamic capacity tables

Frank,

First, many thanks for releasing this code.  But there are a few COPY members 
missing:

DYNTABCR
DYNTABIN
DYNTABRS
DYNTABRL
TXN

I can probably intuit the contents and re-create them based on your descriptive 
comments, but is there a chance you can release your versions?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Monday, August 08, 2016 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Enterprise COBOL API for dynamic capacity tables

Until such time that IBM decides they are worth it, you are free to use this.

https://www.ibm.com/developerworks/community/forums/html/topic?id=e1a34f6a-7ff5-48cf-bd78-d88c792571e0&ps=25

Frank
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

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

[Farley, Peter x23353]

Frank,

First, many thanks for releasing this code.  But there are a few COPY members 
missing:

DYNTABCR
DYNTABIN
DYNTABRS
DYNTABRL
TXN

I can probably intuit the contents and re-create them based on your descriptive 
comments, but is there a chance you can release your versions?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Monday, August 08, 2016 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Enterprise COBOL API for dynamic capacity tables

Until such time that IBM decides they are worth it, you are free to use this.

https://www.ibm.com/developerworks/community/forums/html/topic?id=e1a34f6a-7ff5-48cf-bd78-d88c792571e0&ps=25

Frank
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

[Frank Swarbrick]

Until such time that IBM decides they are worth it, you are free to use this.

https://www.ibm.com/developerworks/community/forums/html/topic?id=e1a34f6a-7ff5-48cf-bd78-d88c792571e0&ps=25




Frank

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

[Frank Swarbrick]

I used a single separate heap in order so that the RPTSTG(ON) report will 
report "my" storage actions separately from COBOLs:

HEAP statistics:
  Initial size:32768
  Increment size:  32768
  Total heap storage used (sugg. initial size):   368656
  Successful Get Heap requests:   11
  Successful Free Heap requests:   2
  Number of segments allocated:2
  Number of segments freed:0

Additional Heap statistics:
  Successful Create Heap requests: 1
  Successful Discard Heap requests:0
  Total heap storage used: 30088
  Successful Get Heap requests:   20
  Successful Free Heap requests:  16
  Number of segments allocated:2
  Number of segments freed:0



From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, August 8, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

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: Interesting C library file open mis-diagnosis

[Charles Mills]

> Was there a job log message, S213-rc identifying the catenand?

Yes,

15.52.57 JOB01527  IEC141I 
013-18,IGG0191B,xxPL,PLKED,ASSEMOBJ-0009,1D41,LS050A,  325
   325 DATASET.NAME(CZAISAUT)

When I spotted that I figured out the problem. But I started out looking at the 
program (PLINK) listing. When a program says "this is my problem" it ought to 
know what it's talking about, right?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, August 08, 2016 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Interesting C library file open mis-diagnosis

On Mon, 8 Aug 2016 13:16:21 -0700, Charles Mills wrote:

>Not a problem or a complaint; just an observation.
>
>//ASSEMOBJ DD  DSN=DATASET.NAME(CZAARCH),DISP=SHR
>
>As luck would have it, CZAISAUT was missing. However, the diagnostic 
>from the prelinker was
>
>SEVERE ERROR EDC4001: Unable to read DD:ASSEMOBJ(CZAARCH).
> 
No, it's a problem.  A misleading diagnostic should always be considered a 
problem.  But I wonder which control block contains the relevant information.

Too many z/OS components behave as the first catenand were all.

A favorite: if the first catenand of SYSEXEC is a UNIX directory, Rexx fails (I 
forget the exact mesage).  If I make the first catenand an empty temporary PDS 
followed by the same UNIX directory, Rexx finds and executes EXECs in that 
directory.  ETR; WAD.  (Slight
misbehavior: sporadically the EXEC terminates with a program check, but it has 
completed successfully; I lose no data.)

Likewise, AMATERSE refuses to extract an archive in a UNIX file.  But if I 
catenate an empty temporary data set followed by that UNIX file, extraction 
works fine.

U:NIX is still a second class citizen but sometimes, in costume, it can pass.

Was there a job log message, S213-rc identifying the catenand?

-- gil

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

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

Re: Interesting C library file open mis-diagnosis

[Paul Gilmartin]

On Mon, 8 Aug 2016 13:16:21 -0700, Charles Mills wrote:

>Not a problem or a complaint; just an observation.
>
>//ASSEMOBJ DD  DSN=DATASET.NAME(CZAARCH),DISP=SHR
>
>As luck would have it, CZAISAUT was missing. However, the diagnostic from
>the prelinker was
>
>SEVERE ERROR EDC4001: Unable to read DD:ASSEMOBJ(CZAARCH).
> 
No, it's a problem.  A misleading diagnostic should always be considered
a problem.  But I wonder which control block contains the relevant
information.

Too many z/OS components behave as the first catenand were all.

A favorite: if the first catenand of SYSEXEC is a UNIX directory,
Rexx fails (I forget the exact mesage).  If I make the first catenand
an empty temporary PDS followed by the same UNIX directory, Rexx
finds and executes EXECs in that directory.  ETR; WAD.  (Slight
misbehavior: sporadically the EXEC terminates with a program check,
but it has completed successfully; I lose no data.)

Likewise, AMATERSE refuses to extract an archive in a UNIX file.  But
if I catenate an empty temporary data set followed by that UNIX file,
extraction works fine.

U:NIX is still a second class citizen but sometimes, in costume, it
can pass.

Was there a job log message, S213-rc identifying the catenand?

-- gil

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

Interesting C library file open mis-diagnosis

[Charles Mills]

Not a problem or a complaint; just an observation.

I have the following input to the C prelinker:

//ASSEMOBJ DD  DSN=DATASET.NAME(CZAARCH),DISP=SHR  
// DD  DSN=DATASET.NAME(CZACESRV),DISP=SHR 
// DD  DSN=DATASET.NAME(CZ4CSA),DISP=SHR   
// DD  DSN=DATASET.NAME(CZ4DIREC),DISP=SHR 
// DD  DSN=DATASET.NAME(CZADYLPA),DISP=SHR 
// DD  DSN=DATASET.NAME(CZADYNEX),DISP=SHR 
// DD  DSN=DATASET.NAME(CZAESTAE),DISP=SHR 
// DD  DSN=DATASET.NAME(CZAES2LE),DISP=SHR 
// DD  DSN=DATASET.NAME(CZAISAUT),DISP=SHR <=
// DD  DSN=DATASET.NAME(CZAMIA$L),DISP=SHR 
// DD  DSN=DATASET.NAME(CZAMIM$Z),DISP=SHR 
// DD  DSN=DATASET.NAME(CZAWTOML),DISP=SHR 
...
   INCLUDE ASSEMOBJ

As luck would have it, CZAISAUT was missing. However, the diagnostic from
the prelinker was

SEVERE ERROR EDC4001: Unable to read DD:ASSEMOBJ(CZAARCH).

Took me a little while to figure out.

(The job works correctly when the object module is present.)

Charles 

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

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

automount allocuser aggregates

[Roach, Dennis]

In the USS Command Reference under automoune, options allocuser and allocany, 
it states "Do not use this option with HFS-compatible zFS file systems if file 
system aggregates are mounted with the same automount policy because unused 
data sets is likely to be created."

We use aggregate and compat to when we format our user zFS data sets. 

Does anyone know what the risk is and have any advice on what we should change?

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

[Farley, Peter x23353]

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.

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

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

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 if perhaps there should be some sort of 
> ratcheting down as the number of rows gets very large.

The C++ runtime library on z/OS is a commercial offering from Dinkumware. 
Interestingly they use phi as the growth factor. A lot of the choices seem to 
be based on the properties of the memory allocator.  Modern allocators, 
including z/OS LE are configurable, so if you plan to use a growth factor of 2 
then you should look into using heap pools.

I have to admire what you're doing. I used to be application programmer a long 
time ago and COBOL seriously lacks collection classes that we take for granted 
in modern languages.
It would be trivial to write a thin ILC wrapper around the C++ STL to enable 
COBOL to use the C++ container classes like vectors, linked lists, heaps, 
stacks, queues, maps and hash maps. I'm not sure how much demand there seems to 
be for that on the mainframe though.

> 
> From: IBM Mainframe Discussion List  on 
> behalf of David Crayford 
> Sent: Thursday, August 4, 2016 8:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 2014 dynamic capacity tables
>
> On 4/08/2016 2:52 AM, Frank Swarbrick wrote:
>> Even in the case where it does increase the actual allocated capacity, it 
>> does not do it "one row at a time".  Rather, it doubles the current physical 
>> capacity and "reallocates" (using CEECZST) the storage to the new value.  
>> This may or may not actually cause LE storage control to reallocate out of a 
>> different area (copying the existing data from the old allocated area).  If 
>> there is enough room already it does nothing except increase the amount 
>> reserved for your allocation.  And even then, LE has already allocated a 
>> probably larger area prior to this from actual OS storage, depending on the 
>> values in the HEAP runtime option.
> Almost all the dynamic array implementations that I'm aware of, C++ 
> std::vector, Java ArrayList, Python lists, Lua tables, use a growth 
> factor of 1.5. Apparently it's a golden ratio.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: ibm afp print driver for windows 10

[Howard Turetzky]

However, if I had been more alert I would have realized the question was about 
the AFP Print Driver for Windows 
(https://www.infoprint.com/internet/dcfdata.nsf/vwWeb/P4000384). The Print 
Driver should run on IE for Windows 10, but not for Edge. Both Chrome and 
FireFox have deprecated plugins, so at present only IE will be supported.

Apologies for "Share lag"...

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

Re: ibm afp print driver for windows 10

[Howard Turetzky]

The current Viewer, 
https://support.rpp.ricoh-usa.com/internet/dcfdata.nsf/vwWeb/P4000360 should 
run on Windows 10, but is currently unsupported for Windows 10.

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

[Frank Swarbrick]

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


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Monday, August 8, 2016 5: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 if perhaps there should be some sort of 
> ratcheting down as the number of rows gets very large.

The C++ runtime library on z/OS is a commercial offering from
Dinkumware. Interestingly they use phi as the growth factor. A lot of
the choices seem to be based on the
properties of the memory allocator.  Modern allocators, including z/OS
LE are configurable, so if you plan to use a growth factor of 2 then you
should look into using heap pools.

I have to admire what you're doing. I used to be application programmer
a long time ago and COBOL seriously lacks collection classes that we
take for granted in modern languages.
It would be trivial to write a thin ILC wrapper around the C++ STL to
enable COBOL to use the C++ container classes like vectors, linked
lists, heaps, stacks, queues, maps and hash maps. I'm not sure how much
demand there seems to be for that on the mainframe though.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Thursday, August 4, 2016 8:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 2014 dynamic capacity tables
>
> On 4/08/2016 2:52 AM, Frank Swarbrick wrote:
>> Even in the case where it does increase the actual allocated capacity, it 
>> does not do it "one row at a time".  Rather, it doubles the current physical 
>> capacity and "reallocates" (using CEECZST) the storage to the new value.  
>> This may or may not actually cause LE storage control to reallocate out of a 
>> different area (copying the existing data from the old allocated area).  If 
>> there is enough room already it does nothing except increase the amount 
>> reserved for your allocation.  And even then, LE has already allocated a 
>> probably larger area prior to this from actual OS storage, depending on the 
>> values in the HEAP runtime option.
> Almost all the dynamic array implementations that I'm aware of, C++
> std::vector, Java ArrayList, Python lists, Lua tables, use a growth
> factor of 1.5. Apparently it's a golden ratio.
>
> --
> 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: SHARE Atlanta proceedings

[Roger Lowe]

If you use Firefox, you could try and (still) use the FF extension (DownThemAll 
aka dTa) - http://www.downthemall.net/

Roger
 
On Mon, 8 Aug 2016 10:02:09 -0400, Richards, Robert B. 
 wrote:

>Thanks Lizette.  One at a time, it is. 
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Lizette Koehler
>Sent: Monday, August 08, 2016 9:47 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: SHARE Atlanta proceedings
>
>I think when you attend Share you might get a DVD with all of the proceedings.
>Otherwise the website I think is just one at a time for download.
>
>Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Richards, Robert B.
>> Sent: Monday, August 08, 2016 5:40 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: SHARE Atlanta proceedings
>> 
>> 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
>
>--
>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

[Richards, Robert B.]

Thanks Lizette.  One at a time, it is. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, August 08, 2016 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SHARE Atlanta proceedings

I think when you attend Share you might get a DVD with all of the proceedings.
Otherwise the website I think is just one at a time for download.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Richards, Robert B.
> Sent: Monday, August 08, 2016 5:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SHARE Atlanta proceedings
> 
> 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

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

[Lizette Koehler]

I think when you attend Share you might get a DVD with all of the proceedings.
Otherwise the website I think is just one at a time for download.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Richards, Robert B.
> Sent: Monday, August 08, 2016 5:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SHARE Atlanta proceedings
> 
> 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

Re: SHARE Atlanta proceedings

[Richards, Robert B.]

Is there an easier way to get and download the presentations other than 
clicking on each individual session? I'm thinking it used to be easier, but I 
may be wrong.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Monday, August 08, 2016 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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=AXicE3RmqN3EwOC5n4GhKKfSwCJDr7ioTC83MTMnOT-vpCg_Ry85P5eh1NzCucAz0tzA2NTMyJAhKD8ptahELygzOSOxKKXYwT_AV8_dP4who6SkwEpfv7y8XK84I78oOzUvBaydgeHhLgYGAC75In8&Z
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: SHARE Atlanta proceedings

[Mike Shorkend]

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
www.shorkend.com
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

SHARE Atlanta proceedings

[Richards, Robert B.]

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

Re: COBOL 2014 dynamic capacity tables

[David Crayford]

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 if perhaps there should be some sort of ratcheting down as the number of rows gets 
very large.


The C++ runtime library on z/OS is a commercial offering from 
Dinkumware. Interestingly they use phi as the growth factor. A lot of 
the choices seem to be based on the
properties of the memory allocator.  Modern allocators, including z/OS 
LE are configurable, so if you plan to use a growth factor of 2 then you 
should look into using heap pools.


I have to admire what you're doing. I used to be application programmer 
a long time ago and COBOL seriously lacks collection classes that we 
take for granted in modern languages.
It would be trivial to write a thin ILC wrapper around the C++ STL to 
enable COBOL to use the C++ container classes like vectors, linked 
lists, heaps, stacks, queues, maps and hash maps. I'm not sure how much 
demand there seems to be for that on the mainframe though.




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

On 4/08/2016 2:52 AM, Frank Swarbrick wrote:

Even in the case where it does increase the actual allocated capacity, it does not do it "one 
row at a time".  Rather, it doubles the current physical capacity and "reallocates" 
(using CEECZST) the storage to the new value.  This may or may not actually cause LE storage 
control to reallocate out of a different area (copying the existing data from the old allocated 
area).  If there is enough room already it does nothing except increase the amount reserved for 
your allocation.  And even then, LE has already allocated a probably larger area prior to this from 
actual OS storage, depending on the values in the HEAP runtime option.

Almost all the dynamic array implementations that I'm aware of, C++
std::vector, Java ArrayList, Python lists, Lua tables, use a growth
factor of 1.5. Apparently it's a golden ratio.

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