Re: Adding Module to a empty APFed Library

[Chris Hoelscher]

All the more reason???

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 Lizette Koehler
> Sent: Wednesday, August 03, 2016 11:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Adding Module to a empty APFed Library
> 
> Just a note.  Auditors hate it when we have an APF list entry with no dataset.
> Makes them cringe.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of R.S.
> > Sent: Wednesday, August 03, 2016 7:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Adding Module to a empty APFed Library
> >
> > W dniu 2016-08-03 o 13:29, Peter pisze:
> > > hello,
> > >
> > > I am trying to understand if an Empty PDS is added to APF list and
> > > later a module is placed into it. So does it have any impact from
> > > the Program call perspective ? Will the newly loaded module into the
> > > Empty APFlist would be taken into account ?
> > Yes, you can add/delete modules to APF-listed library. It is checked
> > during load module fetch (call, read...).
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> 
> --
> 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: request -- Thanks

[Lizette Koehler]

Another method is to search the archives with this URL.  Friendly Web Interface

General MVS IBM-Mainhttps://listserv.ua.edu/archives/ibm-main.html

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, August 03, 2016 6:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: request -- Thanks
> 
> SEARCH iconv in IBM-MAIN WHERE AUTHOR CONTAINS PaulG thanks
> 

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

Re: request -- Thanks

[Edward Finnell]

--> Send searches to _lists...@listserv.ua.edu_ 
(mailto:lists...@listserv.ua.edu) 
--->Not to the Ibm-main list..tnx
 
 
>In a message dated 8/3/2016 8:53:22 P.M. Central Daylight Time,  
000433f07816-dmarc->requ...@listserv.ua.edu writes:

>SEARCH iconv in IBM-MAIN WHERE AUTHOR CONTAINS  PaulG

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

request -- Thanks

[Paul Gilmartin]

SEARCH iconv in IBM-MAIN WHERE AUTHOR CONTAINS PaulG
thanks

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

Re: Adding Module to an empty APFed Library

[Walt Farrell]

On Wed, 3 Aug 2016 17:17:51 -0700, retired mainframer 
 wrote:

>If an empty dataset is on the APF list, it already exists.  Why it exists and 
>why it is on the list are different questions.
>
>Adding a member to an existing empty dataset is NO different than adding a 
>member to an existing populated one.
>
>What is the additional exposure?

I don't think we've said having an empty data set is an exposure. The exposure 
comes from having an APF entry for a data set that does not exist at all.

-- 
Walt

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

Re: Adding Module to an empty APFed Library

[retired mainframer]

If an empty dataset is on the APF list, it already exists.  Why it exists and 
why it is on the list are different questions.

Adding a member to an existing empty dataset is NO different than adding a 
member to an existing populated one.

What is the additional exposure?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Wednesday, August 03, 2016 11:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to an empty APFed Library
> 
> Because you should minimize the APF list to the smallest possible set. A 
> dataset that does
> not exist is a dataset that does not need to be in the APF list.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of retired mainframer
> Sent: Wednesday, August 03, 2016 12:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to an empty APFed Library
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lizette Koehler
> > Sent: Wednesday, August 03, 2016 8:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Adding Module to a empty APFed Library
> >
> > Just a note.  Auditors hate it when we have an APF list entry with no
> > dataset.  Makes them cringe.
> 
> I wonder why.  The only time it would have any effect is if something is 
> added to it.
> Adding to an empty APF library is hardly different than adding to a populated 
> one.
> 
> Did they ever discuss what additional exposure they thought it created?

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

And wouldn't it be even nicer if you didn't need to call subroutines, but could 
just use features of the language itself?!  :-)

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Wednesday, August 3, 2016 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL 2014 dynamic capacity tables

Well, Peter, there is much in what you say, but be careful of quotes.

"Mmm... I smell gas in this dark cellar, has anyone got a match...?" - was the 
person ignorant of the rapid combustion of said gas when a flame is introduced, 
or just stupid? Same question for the match provider, and the others with them. 
Given the chance to question the fleeing ghosts, you'd probably hear "we needed 
light, we've always done it that way".

How to improve Mainframe COBOL programmers is way off this topic.

Yes, explain, but also hide it away. I normally dislike the idea that "then 
some magic happens" in programming, but for the out-of-the-ordinary which is 
not part of the business logic, stick it in a sub-program (can be embedded 
these days, and included within a copybook, and the nice compiler will even be 
able to consider it for "inlining" so you may be able to have your cake and eat 
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: COBOL 2014 dynamic capacity tables

[Frank Swarbrick]

I don't look down on "mere programmers", and in fact am often quite offended 
when people on this list appear to be disparaging them.  But I do have to be 
realistic to know what most COBOL programmers (at least where I work) are not 
"techies", but rather people who "implement automated business logic".  And 
indeed there is nothing wrong with this, most are quite good at it, even if I 
often cringe at the resulting code.  But any time I come up with a solution to 
something that "seems too technical" its generally not implemented.


My "roll my own" dynamic tables have not yet been presented in-house, but along 
with some copybooks I've developed to make it even more "developer friendly", I 
have a good feeling that people will respond well to it (especially considering 
how often they are called in the middle of the night because a "table ran out 
of room"!).  We shall see.


As much as I am happy with my solution, I would still prefer a COBOL language 
solution.


Frank


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, August 3, 2016 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

Now, now gentlemen, let's not look down on mere programmers (I resemble that 
remark!)  -- Remember the saying from author Robert Heinlein's "The Moon is a 
Harsh Mistress":

"Ignorance is curable, only stupidity is fatal."

If employers have not provided sufficient training time and dollars, what else 
but ignorance do you expect?

Try issuing a technical note or two to the ignorant telling them about the 
wonderful things the system can do for them (best if the notes include examples 
the ignoranti can try for themselves of course).  We do that here (well, at 
least Victor and I do) and call them DYKT's (Did You Know That . . . ).  The 
response is sometimes quite positive.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Wednesday, August 03, 2016 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


Frank


From: IBM Mainframe Discussion List  on behalf of 
Victor Gil 
Sent: Wednesday, August 3, 2016 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

I am not sure why would you want the compiler to handle such a general case of 
maintaining a dynamic-size table, while this can be easily programmed by using 
the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a 
callable service.

We do this kind of dynamic table management all the time, under CICS [i.e. 
using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here  is how to 
safely re-size a table which has reached its allocated capacity. This shouldn't 
be an issue in batch where the storage is owned by a single task because it can 
just wait for the call to come back while the subroutine allocates a new larger 
size table and populates it from the old one.

So if you ask the compiler to perform such a function it would have to know how 
to serialize storage access between multiple concurrent tasks and, moreover, 
let the in-flight transactions to keep accessing the old table while the new 
one is being allocated and populated.  Pretty difficult for a general case.

-Victor-

--
Last year I submitted an RFE 
(https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=73693) 
that Enterprise COBOL be enhanced to support dynamic capacity tables as defined 
in the COBOL 2014 ISO standard.  It was declined: "Thank you for bringing this 
RFE to our attention. But we believe that if implemented, it will be really 
slow and error prone.Some clients may have restrictions on using this. This 
is not in our multi-year strategy. Hence, we'll have to reject this RFE."


Since the year has passed I have resubmitted the RFE, now with the following 
comments that I hope might address IBM's concerns:


"This RFE was declined based on concerns about performance.I would like to 
submit the following possibilities 

COBOL 2014 dynamic capacity tables

[Bill Woodger]

Well, Peter, there is much in what you say, but be careful of quotes.

"Mmm... I smell gas in this dark cellar, has anyone got a match...?" - was the 
person ignorant of the rapid combustion of said gas when a flame is introduced, 
or just stupid? Same question for the match provider, and the others with them. 
Given the chance to question the fleeing ghosts, you'd probably hear "we needed 
light, we've always done it that way".

How to improve Mainframe COBOL programmers is way off this topic.

Yes, explain, but also hide it away. I normally dislike the idea that "then 
some magic happens" in programming, but for the out-of-the-ordinary which is 
not part of the business logic, stick it in a sub-program (can be embedded 
these days, and included within a copybook, and the nice compiler will even be 
able to consider it for "inlining" so you may be able to have your cake and eat 
it. 

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

Now, now gentlemen, let's not look down on mere programmers (I resemble that 
remark!)  -- Remember the saying from author Robert Heinlein's "The Moon is a 
Harsh Mistress":

"Ignorance is curable, only stupidity is fatal."

If employers have not provided sufficient training time and dollars, what else 
but ignorance do you expect?

Try issuing a technical note or two to the ignorant telling them about the 
wonderful things the system can do for them (best if the notes include examples 
the ignoranti can try for themselves of course).  We do that here (well, at 
least Victor and I do) and call them DYKT's (Did You Know That . . . ).  The 
response is sometimes quite positive.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Wednesday, August 03, 2016 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


Frank


From: IBM Mainframe Discussion List  on behalf of 
Victor Gil 
Sent: Wednesday, August 3, 2016 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

I am not sure why would you want the compiler to handle such a general case of 
maintaining a dynamic-size table, while this can be easily programmed by using 
the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a 
callable service.

We do this kind of dynamic table management all the time, under CICS [i.e. 
using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here  is how to 
safely re-size a table which has reached its allocated capacity. This shouldn't 
be an issue in batch where the storage is owned by a single task because it can 
just wait for the call to come back while the subroutine allocates a new larger 
size table and populates it from the old one.

So if you ask the compiler to perform such a function it would have to know how 
to serialize storage access between multiple concurrent tasks and, moreover, 
let the in-flight transactions to keep accessing the old table while the new 
one is being allocated and populated.  Pretty difficult for a general case.

-Victor-

--
Last year I submitted an RFE 
(https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=73693) 
that Enterprise COBOL be enhanced to support dynamic capacity tables as defined 
in the COBOL 2014 ISO standard.  It was declined: "Thank you for bringing this 
RFE to our attention. But we believe that if implemented, it will be really 
slow and error prone.Some clients may have restrictions on using this. This 
is not in our multi-year strategy. Hence, we'll have to reject this RFE."


Since the year has passed I have resubmitted the RFE, now with the following 
comments that I hope might address IBM's concerns:


"This RFE was declined based on concerns about performance.I would like to 
submit the following possibilities for consideration:

Would IBM be more amenable to a partial implementation? while you did not 
indicate in the declined RFE what performance issues you foresee,I can 
hazzard some guesses.One is the requirement in the standard is 8.5.1.6.3.2 
Implicit changes in capacity: "When a data item in a dynamic-capacity table is 
referenced as a receiving item and the value of the subscript exceeds the 
current capacity of the table, a new element is automatically created and the 
capacity of the table is increased to the value given by the subscript. If this 
new capacity is more than one greater than the previous
capacity, new intermediate occurrences are implicitly created."I believe 
this would require a runtime check in each of these cases to see if the 
subscript is greater than the current capacity, and if so to increase the 
current capacity.

The current capacity can also be increased explicitly.8.5.1.6.3.3 states 
"If the OCCURS clause specifies a CAPACITY phrase, the capacity of the 
dynamic-capacity table may be increased or decreased explicitly by means of the 
dynamic-capacity-table format SET statement."The "implicit changes" was one 
of the arguments I've seen against implementation of dynamic capacity tables, 
with the 

COBOL 2014 dynamic capacity tables

[Bill Woodger]

I think that is the correct way to do it, Frank. The chunk-size of "20" is 
obviously determined by whatever best fits the data use. I'd go for the old 
"table size you expect, and then a bit" but doing the "and then a bit" by 
extending it.

For batch it doesn't matter, but for other usage you do need to be aware that 
the address of the start of the table may change. If "something else" has the 
old address (when there is an old address) then something is going to behave 
less than optimally.

The difference in your example to what you mentioned earlier is that the 
storage is entirely contiguous, and, since it is "defined" in the LINKAGE 
SECTION (a mapping of storage, with storage acquired for it) then nothing else 
gets upset.

If you remember from a while ago I thought the UNBOUNDED *was* IBM's 
implementation of dynamic tables.

Here's another example of what I presume your code is doing, generally 
(although you have the better idea with the chunks) 
http://enterprisesystemsmedia.com/article/leveraging-cobol-language-environment-services#sr=g=o=or=-tmc=(opu%20qspwjefe)=1470260061

The actual dynamic tables (or the possibilities) described in the current 
Standard I regard as a nightmare. Even let's assume that all the dynamic table 
storage is consecutive. Well, you can get nested, and you can mix them with 
fixed or ODO tables under the same group item. Yes, you could implicitly 
untangle that, but at what cost? What about REDEFINES? Yes, you can ban it, 
like for an ODO, but for an ODO you can still achieve REDEFINES. Try to do that 
with the proposed junk, and there's a mess.

IBM has just rewritten the compiler, including work on WORKING-STORAGE and 
LOCAL-STORAGE. Anything with a dynamic capacity table would have to have its 
own storage allocated, separate from the WORKING-STORAGE/LOCAL-STORAGE 
allocation (so you end up with multiples of each).

Let's not get into how programmers may (ab)use it. 

Nor sites which "ban" its use.

So, since UNBOUNDED does what you want in this example, you need a very strong 
case to get dynamic tables addressed, and I don't think such a case exists, 
given the inherent drawbacks.

If it doesn't fit into IBM's plans, which they stated it doesn't when rejecting 
the RFE first time, then you're going to get it rejected again.

I don't doubt that it would be great fun to play with, outside the Mainframe, 
and really welcome anything you can produce for GnuCOBOL, but I'm not sure 
you're going to get anywhere with Enterprise COBOL.

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

Re: TCB reference following DETACH

[Rupert Reynolds]

I'm very rusty (as in MVS/ESA), but I'd say yes. I'd normally grab any info
I want before DETACH.
On 3 Aug 2016 9:10 p.m., "Charles Mills"  wrote:

> I am trying to shoot a problem. The code in question makes reference to a
> TCB shortly after issuing a DETACH for that TCB. Am I correct in my
> analysis
> that that is a S0C4 candidate? That once you issue a DETACH, the TCB is no
> longer necessarily valid?
>
> Thanks,
>
> Charles
>
> --
> 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: TCB reference following DETACH

[Charles Mills]

Thanks. I figured ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Greg Dyck
Sent: Wednesday, August 03, 2016 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCB reference following DETACH

On 8/3/2016 1:10 PM, Charles Mills wrote:
> I am trying to shoot a problem. The code in question makes reference 
> to a TCB shortly after issuing a DETACH for that TCB. Am I correct in 
> my analysis that that is a S0C4 candidate? That once you issue a 
> DETACH, the TCB is no longer necessarily valid?

Once you issue a DETACH *all* of the control blocks associated with the TCB
(STCB, RBs, XSBs, etc) has been freed for reuse.  Any reference to that
storage is unpredictable.

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

#1) one should always code for threadsafety regardless...

#2) yes, I did 'code the required service'.  Which doesn't make the requirement 
superfluous by any means.


From: IBM Mainframe Discussion List  on behalf of 
Victor Gil 
Sent: Wednesday, August 3, 2016 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

If the "update a table row" logic has no imbedded CICS commands it won't be 
interrupted by CICS, so the updater will have no competition, thus no 
serialization is required [I am talking about "regular" CICS tasks, dispatched 
on QTCB, not those fancy running on "open TCBs"].
However, it is required during the table re-allocation as the logic does need 
to call CICS for memory re-allocation [which may or may not cause the task to 
get re-dispatched].

Anyway, looks like you have already coded the required service.

-Victor-

---
Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


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: TCB reference following DETACH

[Greg Dyck]

On 8/3/2016 1:10 PM, Charles Mills wrote:

I am trying to shoot a problem. The code in question makes reference to a
TCB shortly after issuing a DETACH for that TCB. Am I correct in my analysis
that that is a S0C4 candidate? That once you issue a DETACH, the TCB is no
longer necessarily valid?


Once you issue a DETACH *all* of the control blocks associated with the 
TCB (STCB, RBs, XSBs, etc) has been freed for reuse.  Any reference to 
that storage is unpredictable.


Greg

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

TCB reference following DETACH

[Charles Mills]

I am trying to shoot a problem. The code in question makes reference to a
TCB shortly after issuing a DETACH for that TCB. Am I correct in my analysis
that that is a S0C4 candidate? That once you issue a DETACH, the TCB is no
longer necessarily valid?

Thanks,

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

[Victor Gil]

If the "update a table row" logic has no imbedded CICS commands it won't be 
interrupted by CICS, so the updater will have no competition, thus no 
serialization is required [I am talking about "regular" CICS tasks, dispatched 
on QTCB, not those fancy running on "open TCBs"].
However, it is required during the table re-allocation as the logic does need 
to call CICS for memory re-allocation [which may or may not cause the task to 
get re-dispatched].

Anyway, looks like you have already coded the required service.

-Victor- 

---
Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


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]

Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


Frank


From: IBM Mainframe Discussion List  on behalf of 
Victor Gil 
Sent: Wednesday, August 3, 2016 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

I am not sure why would you want the compiler to handle such a general case of 
maintaining a dynamic-size table, while this can be easily programmed by using 
the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a 
callable service.

We do this kind of dynamic table management all the time, under CICS [i.e. 
using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here  is how to 
safely re-size a table which has reached its allocated capacity. This shouldn't 
be an issue in batch where the storage is owned by a single task because it can 
just wait for the call to come back while the subroutine allocates a new larger 
size table and populates it from the old one.

So if you ask the compiler to perform such a function it would have to know how 
to serialize storage access between multiple concurrent tasks and, moreover, 
let the in-flight transactions to keep accessing the old table while the new 
one is being allocated and populated.  Pretty difficult for a general case.

-Victor-

--
Last year I submitted an RFE 
(https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=73693) 
that Enterprise COBOL be enhanced to support dynamic capacity tables as defined 
in the COBOL 2014 ISO standard.  It was declined: "Thank you for bringing this 
RFE to our attention. But we believe that if implemented, it will be really 
slow and error prone.Some clients may have restrictions on using this. This 
is not in our multi-year strategy. Hence, we'll have to reject this RFE."


Since the year has passed I have resubmitted the RFE, now with the following 
comments that I hope might address IBM's concerns:


"This RFE was declined based on concerns about performance.I would like to 
submit the following possibilities for consideration:

Would IBM be more amenable to a partial implementation? while you did not 
indicate in the declined RFE what performance issues you foresee,I can 
hazzard some guesses.One is the requirement in the standard is 8.5.1.6.3.2 
Implicit changes in capacity: "When a data item in a dynamic-capacity table is 
referenced as a receiving item and the value of the subscript exceeds the 
current capacity of the table, a new element is automatically created and the 
capacity of the table is increased to the value given by the subscript. If this 
new capacity is more than one greater than the previous
capacity, new intermediate occurrences are implicitly created."I believe 
this would require a runtime check in each of these cases to see if the 
subscript is greater than the current capacity, and if so to increase the 
current capacity.

The current capacity can also be increased explicitly.8.5.1.6.3.3 states 
"If the OCCURS clause specifies a CAPACITY phrase, the capacity of the 
dynamic-capacity table may be increased or decreased explicitly by means of the 
dynamic-capacity-table format SET statement."The "implicit changes" was one 
of the arguments I've seen against implementation of dynamic capacity tables, 
with the concern that one might have a bug that set a subscript to an incorrect 
and possibly very large value, which would cause the table to be increased to 
that value "improperly".

So why not eliminate that requirement as part of the implementation?I can't 
see any problem with a simple "SET tbl-capacity UP BY 1" when intentionally 
adding a new row to the table.


One other feature I can see that could be bypassed, at least initially, would 
be the behavior of the MOVE of a group containing a dynamic capacity table.
Because a d.c. table would most likely not be "physically contiguous" with the 
rest of the items in the table, a MOVE of the entire group would at the very 
least be "less efficient".So how about a restriction that you can't do a 
group MOVE where the group contains one or more dynamic capacity tables?I 
don't see too many uses cases where this would cause an issue, and if we can 
get implementation of 

Re: COBOL 2014 dynamic capacity tables

[Frank Swarbrick]

I am just about finished implementing a set of subroutines that will utilize 
the new(ish) "unbounded table" feature of Enterprise COBOL to support a "pseudo 
dynamic capacity" table.  It works very much how I could imagine it might be 
implemented within the language itself.  Here's a brief overview of how it 
works, and why I believe it's not as bad as you make it out to be.

 LINKAGE SECTION.
 01  CREDIT-TABLE.
 05  CT-ROW-CNT  PIC S9(9) COMP.
 05  CREDIT-ENTRYOCCURS 0 TO UNBOUNDED
DEPENDING ON CT-ROW-CNT
INDEXED BY CREDIT-SUB
 PIC X(125).

 *> do the following one time
 PERFORM CREATE-CREDIT-TABLE

 *> do the following each time you want to insert a new row
 PERFORM INCREMENT-CREDIT-TABLE
 SET CREDIT-SUB TO CT-ROW-CNT
 MOVE TRANSACTION-RECORD TO CREDIT-ENTRY (CREDIT-SUB)

 *> do the following to reset the table back to "no rows"
 PERFORM RESET-CREDIT-TABLE

 *> do the following to release the storage for the table.
 *> not really needed unless you are using the table in a called subroutine
 *> and want to make the storage available once the called routine has 
exited.
 PERFORM RELEASE-CREDIT-TABLE

here are the relevant procedures that actually invoke the 'dynamic table 
routines':

 CREATE-CREDIT-TABLE.
 >>callinterface dll
 call 'dynamic_table_create'
  using value length of CREDIT-ENTRY(1)
value 20
reference address of CREDIT-TABLE
 >>callinterface
 exit paragraph.

 INCREMENT-CREDIT-TABLE.
 >>callinterface dll
 call 'dynamic_table_update_size'
  using reference address of CREDIT-TABLE
value +1
 >>callinterface
 exit paragraph.

 RESET-CREDIT-TABLE.
>>callinterface dll
call 'dynamic_table_reset'
 using reference address of CREDIT-TABLE
>>callinterface
exit paragraph.

 RELEASE-CREDIT-TABLE.
 >>callinterface dll
 call 'dynamic_table_release'
  using reference address of CREDIT-TABLE
 >>callinterface
 exit paragraph.

'dynamic_table_create' is a routine that uses CEEGTST to allocate enough space 
to hold:
- a 20 byte "control block" (invisable to the caller)
- a fullword "current capacity" field (represented as CT-ROW-CNT in this 
example)
- the number of rows specified by parameter 2 (20, in this case).

Note that the "current capacity" field is initially set to 0, even though there 
is enough space to hold 20 rows.  This means that as you call 
'dynamic_table_update_size' to "add a new row" to the table, it does not call 
storage management until the time when the current capacity would exceed the 
"current physical capacity" (a value stored in the control block mentioned 
above).

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.

'dynamic_table_reset' itself just calls the 'dynamic_table_update_size' routine 
with parameter 2 being "0 - current (logical) capacity".  Essentially it sets 
the current logical capacity back to 0.  This causes 
'dynamic_table_update_size' to do a call to CEECZST to set the physical 
allocation back to the initial physical allocation (that value also having been 
stored in the control block area).  This routine would only be used in the case 
where you want to "reset the table" back to zero records several times in a 
program.  Not a common occurence, I imagine, but my test case (a real life 
production program!) does have one situation where this is required.  
Specifically, CREDIT-TABLE represents all of the credits for one customer 
account on any one day.  Once we're done with the current account we "reset" 
the table to "start over" for the next account.

'dynamic_table_release' simply calls CEEFRST to release the storage and set the 
parameter (the address of the table) to NULL.

All of this has been tested extensively with one real life production program 
that has FIVE tables that I converted to use these new routines.

I intend to post the source code for these routines to the "IBM COBOL Cafe" as 
soon as I can get a good "test case" that is not an actual production program!  
:-)

I'm sure most people have not read this far, but if you have I welcome any 
comments.

None of this eliminates my desire for IBM to implement language support for 
dynamic 

HTTP Client post method mistery

[Itschak Mugzach]

My program (assembler) uses the http enabelment toolkit using POST method.
I pass the data in the request body in a form of "aaa=123". The server
returns http200, but not recognize the data (but recognize the method). the
log looks like the one below. It is clear that I am missing something, but
what? BTW, I tried to add a content header and a blank line (using 'odoa'x
that worked very well in formatting, but gave same results. Below please
find the log (Verbose mode).

ITschak

t: * * * * * HTTP REQUEST HEADERS * * * *
*
t: POST /test.php
HTTP/1.1


Host:
xx.xx.xx.xx


Content-Length:
9






t: * * * * * END HTTP REQUEST HEADERS * * * *
*
t-Entry:
translate
t-Exit:
translate
t: * * * HTTP REQUEST BODY * *
*
t:
aaa=123
t: * * * END HTTP REQUEST BODY * *
*
t-Entry:
translate
t-Exit:
translate
t-Entry:
doSend
t:
send()

t:   bytes sent:
75
t:   total bytes:
75
t:   bytes remaining:
75
t: HTTP message sent
successfully.
t-Exit:
doSend
t-Exit:
sendrqstImpl
t-Entry:
recvresp
t-Entry:
recvrespImpl
t: Client received 232
bytes.
t-Entry:
translate
t-Exit:
translate
t: HTTP status =
200
t: HTTP version =
HTTP/1.1
t: HTTP reason =
OK
t: Header: Date = Wed, 03 Aug 2016 17:57:43
GMT
t-Entry:
headerCallback
t-Exit:
headerCallback
t: Header: Server = Apache/2.4.10 (Unix) OpenSSL/1.0.1j PHP/5.6.3
mod_perl/2.0.8


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

Re: Adding Module to an empty APFed Library

[Charles Mills]

Because you should minimize the APF list to the smallest possible set. A 
dataset that does not exist is a dataset that does not need to be in the APF 
list.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Wednesday, August 03, 2016 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, August 03, 2016 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to a empty APFed Library
> 
> Just a note.  Auditors hate it when we have an APF list entry with no 
> dataset.  Makes them cringe.

I wonder why.  The only time it would have any effect is if something is added 
to it.  Adding to an empty APF library is hardly different than adding to a 
populated one.

Did they ever discuss what additional exposure they thought it created?

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

Re: Adding Module to an empty APFed Library

[Walt Farrell]

On Wed, 3 Aug 2016 09:39:01 -0700, retired mainframer 
 wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Lizette Koehler
>> Sent: Wednesday, August 03, 2016 8:07 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Adding Module to a empty APFed Library
>> 
>> Just a note.  Auditors hate it when we have an APF list entry with no 
>> dataset.  Makes them
>> cringe.
>
>I wonder why.  The only time it would have any effect is if something is added 
>to it.  Adding to an empty APF library is hardly different than adding to a 
>populated one.
>
>Did they ever discuss what additional exposure they thought it created?

If the data set exists, you can verify how it is protected and ensure that only 
appropriate users can update it. 

If the data set does not exist, then you have to worry about two things:
(1) Who can create it, which is harder to determine than figuring out who can 
access a data set that already exists; and
(2) Will it be protected properly when someone does create it.

Additionally, if the data set exists you can examine the modules in it and 
check for various security/integrity exposures, such as inappropriate modules 
having AC(1). You can't do that for a data set that doesn't yet exist.

-- 
Walt

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

Re: Adding Module to an empty APFed Library

[Charles Mills]

http://m.isaca.org/Education/Conferences/Pages/GRC-registration.aspx 


CharlesSent from a mobile; please excuse the brevity

 Original message 
From: "Rugen, Len"  
Date: 8/3/16  12:41 PM  (GMT-05:00) 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Adding Module to an empty APFed Library 

I think auditors must have an annual convention and decide what to add to their 
checklist at some SCIDS equivalent.  

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu

Myth: If You Can’t Measure It, You Can’t Manage It, but if you have data, it’s 
not cheating to use it.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Wednesday, August 03, 2016 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, August 03, 2016 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to a empty APFed Library
> 
> Just a note.  Auditors hate it when we have an APF list entry with no 
> dataset.  Makes them cringe.

I wonder why.  The only time it would have any effect is if something is added 
to it.  Adding to an empty APF library is hardly different than adding to a 
populated one.

Did they ever discuss what additional exposure they thought it created?

--
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: Adding Module to a empty APFed Library

[retired mainframer]

APF libraries are not searched for a module the way LNKLST ones are.  Nor are 
consolidated DEB and BLDL built for them at IPL the way they are for the 
LNKLST.  Even the order of the APF list has no effect.

When an AC(1) module is loaded, the decision to honor the authorization is made 
(in part) by searching the **current** APF list for the DSN and volume for an 
entry that matches where the module was found.  When the library was placed on 
the list and when the module was placed in the library are not part of this 
search.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Wednesday, August 03, 2016 4:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Adding Module to a empty APFed Library
> 
> hello,
> 
> I am trying to understand if an Empty PDS is added to APF list and later a
> module is placed into it. So does it have any impact from the Program call
> perspective ? Will the newly loaded module into the Empty APFlist would be
> taken into account ?

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

Re: Adding Module to an empty APFed Library

[Rugen, Len]

I think auditors must have an annual convention and decide what to add to their 
checklist at some SCIDS equivalent.  

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu

Myth: If You Can’t Measure It, You Can’t Manage It, but if you have data, it’s 
not cheating to use it.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Wednesday, August 03, 2016 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, August 03, 2016 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to a empty APFed Library
> 
> Just a note.  Auditors hate it when we have an APF list entry with no 
> dataset.  Makes them cringe.

I wonder why.  The only time it would have any effect is if something is added 
to it.  Adding to an empty APF library is hardly different than adding to a 
populated one.

Did they ever discuss what additional exposure they thought it created?

--
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: Adding Module to an empty APFed Library

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, August 03, 2016 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to a empty APFed Library
> 
> Just a note.  Auditors hate it when we have an APF list entry with no 
> dataset.  Makes them
> cringe.

I wonder why.  The only time it would have any effect is if something is added 
to it.  Adding to an empty APF library is hardly different than adding to a 
populated one.

Did they ever discuss what additional exposure they thought it created?

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

Re: JES2 can't find customised start-up parameters

[Tom Marchant]

On Wed, 3 Aug 2016 08:10:25 -0700, Lizette Koehler wrote:

>My preference is to always code a HASPPARM dd statement.  That way you do not 
>get a misleading 
>IEC130I HASPPARM DD STATEMENT MISSING
>
>message which could distract from the true issue.  Also provides better 
>documentation in JES2 where the member is coming from.  

OTOH, that means that you do not use the system PARMLIB concatenation for your 
JES2 parameters. 

-- 
Tom Marchant

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

Re: IEFU8* exit points and RMF type 70

[Charles Mills]

No SVC's allowed if you come through IEFU85.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Hare
Sent: Wednesday, August 03, 2016 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEFU8* exit points and RMF type 70

Someone wants a WTO that shows SMF70LAC  (the 4-hour rolling average of MSUs 
value)  every time the RMF type 70 is written.   IEFU8* is the best exit point 
to do that, as near as I can tell,  however what I don't know is whether type 
70s are written the "normal" way, via branch-entry, or via cross-memory,  
require the record be examined at the respective 83, 84, or 85 exit point.  

At this point, I'd probably write the exit and name it as one of the modules at 
all of the exit points - as long as I do my WTO in a reentrant manner I should 
be OK,  but  I'd still kind of like to know the answer.

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

IEFU8* exit points and RMF type 70

[Tim Hare]

Someone wants a WTO that shows SMF70LAC  (the 4-hour rolling average of MSUs 
value)  every time the RMF type 70 is written.   IEFU8* is the best exit point 
to do that, as near as I can tell,  however what I don't know is whether type 
70s are written the "normal" way, via branch-entry, or via cross-memory,  
require the record be examined at the respective 83, 84, or 85 exit point.  

At this point, I'd probably write the exit and name it as one of the modules at 
all of the exit points - as long as I do my WTO in a reentrant manner I should 
be OK,  but  I'd still kind of like to know the answer.

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

Re: JES2 can't find customised start-up parameters

[John McKown]

On Wed, Aug 3, 2016 at 10:10 AM, Lizette Koehler 
wrote:

> My preference is to always code a HASPPARM dd statement.  That way you do
> not get a misleading
> IEC130I HASPPARM DD STATEMENT MISSING
>
> ​m​
> essage which could distract from the true issue.  Also provides better
> documentation in JES2 where the member is coming from.  Defaults are fine,
> unless you do not know the rules.  Sysprogs of the future may not
> understand how JES2 gets its init deck.
>

I was going to comment on the truth of this. But I got so sarcastic that
even I got offended.


> Lizette
>
>
>
-- 
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: TS7720 GRID change

[Throckmorton, Scott S [IT]]

Last time we performed a change like you are describing we were at code level 
32.01.0008 and it did require a bounce of the VTS.
It was to bounce the IP stack.  At that code level the only way to perform that 
IP release/renew was to bounce the VTS.
It has been some time ago...code level 32.01.0008
Hopefully someone with more current experience or knowledge of later code 
levels will enlighten if this has changed.

Scott Throckmorton



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Reddy
Sent: Wednesday, August 03, 2016 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TS7720 GRID change

Has anyone ever changed the network for their TS7720 GRID  -by that I mean, 
changed the IP addresses and gateways that are used for the 2 or 4 grid 
replication WAN links, and swapped the cabling, during a switch upgrade for 
example? I am curious if the VEB has to be taken offline for such an update, or 
if the machine only needs to be in service prep?

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



This e-mail may contain Sprint proprietary information intended for the sole 
use of the recipient(s). Any use by others is prohibited. If you are not the 
intended recipient, please contact the sender and delete all copies of the 
message.

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

Re: JES2 can't find customised start-up parameters

[Lizette Koehler]

My preference is to always code a HASPPARM dd statement.  That way you do not 
get a misleading 
IEC130I HASPPARM DD STATEMENT MISSING

message which could distract from the true issue.  Also provides better 
documentation in JES2 where the member is coming from.  Defaults are fine, 
unless you do not know the rules.  Sysprogs of the future may not understand 
how JES2 gets its init deck.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vince Getgood
> Sent: Wednesday, August 03, 2016 6:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 can't find customised start-up parameters
> 
> Thanks for your help everyone.
> 
> It was indeed the parenthesis.  Once I replied using quotes instead of
> brackets, JES2 started fine.
> 
> Lizette, no need for a HASPPARM DD statement in the JES2 PROC.  There's a
> SHARE presentation around that has a JES2 procedure even more minimalistic
> than mine!
> 

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

Re: Adding Module to a empty APFed Library

[Lizette Koehler]

Just a note.  Auditors hate it when we have an APF list entry with no dataset.  
Makes them cringe.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Wednesday, August 03, 2016 7:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding Module to a empty APFed Library
> 
> W dniu 2016-08-03 o 13:29, Peter pisze:
> > hello,
> >
> > I am trying to understand if an Empty PDS is added to APF list and
> > later a module is placed into it. So does it have any impact from the
> > Program call perspective ? Will the newly loaded module into the Empty
> > APFlist would be taken into account ?
> Yes, you can add/delete modules to APF-listed library. It is checked during
> load module fetch (call, read...).
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

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

TS7720 GRID change

[Mike Reddy]

Has anyone ever changed the network for their TS7720 GRID  -by that I mean, 
changed the IP addresses and gateways that are used for the 2 or 4 grid 
replication WAN links, and swapped the cabling, during a switch upgrade for 
example? I am curious if the VEB has to be taken offline for such an update, or 
if the machine only needs to be in service prep?

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

[Victor Gil]

I am not sure why would you want the compiler to handle such a general case of 
maintaining a dynamic-size table, while this can be easily programmed by using 
the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a 
callable service.

We do this kind of dynamic table management all the time, under CICS [i.e. 
using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here  is how to 
safely re-size a table which has reached its allocated capacity. This shouldn't 
be an issue in batch where the storage is owned by a single task because it can 
just wait for the call to come back while the subroutine allocates a new larger 
size table and populates it from the old one.

So if you ask the compiler to perform such a function it would have to know how 
to serialize storage access between multiple concurrent tasks and, moreover, 
let the in-flight transactions to keep accessing the old table while the new 
one is being allocated and populated.  Pretty difficult for a general case.

-Victor-

--
Last year I submitted an RFE 
(https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=73693) 
that Enterprise COBOL be enhanced to support dynamic capacity tables as defined 
in the COBOL 2014 ISO standard.  It was declined: "Thank you for bringing this 
RFE to our attention. But we believe that if implemented, it will be really 
slow and error prone.Some clients may have restrictions on using this. This 
is not in our multi-year strategy. Hence, we'll have to reject this RFE."


Since the year has passed I have resubmitted the RFE, now with the following 
comments that I hope might address IBM's concerns:


"This RFE was declined based on concerns about performance.I would like to 
submit the following possibilities for consideration:

Would IBM be more amenable to a partial implementation? while you did not 
indicate in the declined RFE what performance issues you foresee,I can 
hazzard some guesses.One is the requirement in the standard is 8.5.1.6.3.2 
Implicit changes in capacity: "When a data item in a dynamic-capacity table is 
referenced as a receiving item and the value of the subscript exceeds the 
current capacity of the table, a new element is automatically created and the 
capacity of the table is increased to the value given by the subscript. If this 
new capacity is more than one greater than the previous
capacity, new intermediate occurrences are implicitly created."I believe 
this would require a runtime check in each of these cases to see if the 
subscript is greater than the current capacity, and if so to increase the 
current capacity.

The current capacity can also be increased explicitly.8.5.1.6.3.3 states 
"If the OCCURS clause specifies a CAPACITY phrase, the capacity of the 
dynamic-capacity table may be increased or decreased explicitly by means of the 
dynamic-capacity-table format SET statement."The "implicit changes" was one 
of the arguments I've seen against implementation of dynamic capacity tables, 
with the concern that one might have a bug that set a subscript to an incorrect 
and possibly very large value, which would cause the table to be increased to 
that value "improperly".

So why not eliminate that requirement as part of the implementation?I can't 
see any problem with a simple "SET tbl-capacity UP BY 1" when intentionally 
adding a new row to the table.


One other feature I can see that could be bypassed, at least initially, would 
be the behavior of the MOVE of a group containing a dynamic capacity table.
Because a d.c. table would most likely not be "physically contiguous" with the 
rest of the items in the table, a MOVE of the entire group would at the very 
least be "less efficient".So how about a restriction that you can't do a 
group MOVE where the group contains one or more dynamic capacity tables?I 
don't see too many uses cases where this would cause an issue, and if we can 
get implementation of the most important features, that is better than nothing 
at all?"


I still believe this would be one of the most useful enhancements that COBOL 
could have.  Please vote if you agree.  (There is also a similar SHARE 
requirement.)


My resubmitted RFE: 
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=92391

Share Requirement: http://www.share.org/index.php?mo=is=vi=67=23


Frank Swarbrick

Principal Analyst, Mainframe Applications

FirstBank -- Lakewood, CO USA

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

Re: Adding Module to a empty APFed Library

[R.S.]

W dniu 2016-08-03 o 13:29, Peter pisze:

hello,

I am trying to understand if an Empty PDS is added to APF list and later a
module is placed into it. So does it have any impact from the Program call
perspective ? Will the newly loaded module into the Empty APFlist would be
taken into account ?
Yes, you can add/delete modules to APF-listed library. It is checked 
during load module fetch (call, read...).


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: JES2 can't find customised start-up parameters

[Vince Getgood]

Thanks for your help everyone.

It was indeed the parenthesis.  Once I replied using quotes instead of 
brackets, JES2 started fine.

Lizette, no need for a HASPPARM DD statement in the JES2 PROC.  There's a SHARE 
presentation around that has a JES2 procedure even more minimalistic than mine!

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

Re: Adding Module to a empty APFed Library

[Charles Mills]

Re-phrasing the question, does it matter to the execution of module X whether 
it was in the library at the time the library was added to the APF list, the 
answer is No. It does not even matter whether the library existed at the time 
it was added to the APF list. That is, you can add MY.DATA.SET to the APF list 
now and create MY.DATA.SET later, and all will work as though you had done 
things in a more normal sequence.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Wednesday, August 03, 2016 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Adding Module to a empty APFed Library

hello,

I am trying to understand if an Empty PDS is added to APF list and later a 
module is placed into it. So does it have any impact from the Program call 
perspective ? Will the newly loaded module into the Empty APFlist would be 
taken into account ?

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

Adding Module to a empty APFed Library

[Peter]

hello,

I am trying to understand if an Empty PDS is added to APF list and later a
module is placed into it. So does it have any impact from the Program call
perspective ? Will the newly loaded module into the Empty APFlist would be
taken into account ?


This is just a question for the knowledge sake.

Peter

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

Re: Black duck

[Gerry Anstey]

Thanks all

It presumably scans for various strings or code sequences but given the ,myriad 
compilers out there and asm code direct I cannot see how it can possibly scan 
for sequences reliably in any object/load module.  

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

COBOL 2014 dynamic capacity tables

[Bill Woodger]

If you are expecting this type of table to non-contiguous in any way, then that 
breaks things.

You couldn't REDEFINES (you could "ban" it. No you can't. REDEFINES is banned 
for OCCURS DEPENDING ON yet I use it a lot).

OK, for SEARCH, you could have special versions of the library routines (great, 
two places to maintain stuff). But what about INSPECT, STRING, UNSTRING? Ban 
those as well.

What about the code 

an-entry ( a-subscript + n ) 

where + is +/- n is a literal numeric value. OK ban it.

What about CALL? Ban it.

What about anything except the particulars of the dynamic capacity table?

So, forget non-contiguous storage. So make the performance issue that of 
keeping the table contiguous, implicitly. Like with any acquiring of storage, 
"adding to it" can be a heavy process. An implicit process. Which newly-trained 
CS people are not used to either knowing about or being concerned about.

Where in the DATA DIVISION would it be? LINKAGE SECTION again (non-Standard). 
WORKING-STORAGE or LOCAL-STORAGE (breaks how they work currently)? 

I don't think everything (by a long stretch) in the  current  COBOL Standard 
(2014, replacing 2002) is a "good fit" for what we (that's me saying "I" and 
hoping not to look entirely isolated) expect for a Mainframe COBOL.

Also, performance was not the only reason. There is "error prone" and also 
these: "Some clients may have restrictions on using this. This is not in our 
multi-year strategy."

It would be good, but perhaps not possible, if IBM were to outline their 
multi-year strategy for COBOL. Avoids the rejection of RFEs which stood no 
chance for that reason.

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

Re: Step-name not displayed correctly (z/os 2.2)

[John Compton]

I found this same problem with our own zpdt box, ITschak.
I didn't solve it as such - just replaced the program module with one from a 
working system.
From memory, that same thing happened with all releases for the z/os v2.1 
support, too.

Regards
John Compton

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: 02 August 2016 22:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Step-name not displayed correctly (z/os 2.2)

Yes. But this is a defalt exit we use on ower zpdt box. Almost 100% vanila.

Best
ITschak
בתאריך 2 באוג 2016 23:27,‏ "Tom Marchant" < 
000a2a8c2020-dmarc-requ...@listserv.ua.edu> כתב:

> On Tue, 2 Aug 2016 22:48:02 +0300, Itschak Mugzach wrote:
>
> >​I am running a job with two steps: COMPILE and LINKEDIT. step-names 
> >are not displayed correctly, both has a value of x'7bad'. the 
> >jobs are doing what they were expected to do. Any idea why step-names 
> >are
> corrupted?
>
> Is this the message from your IEFACTRT exit?
>
> --
> Tom Marchant
>
> --
> 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: JES2 can't find customised start-up parameters

[Lucas Rosalen]

I think Andy nailed it.  Wrong parenthesis in start command.

Lucas

On Aug 2, 2016 21:01, "Lizette Koehler"  wrote:

> The sample JES2 Start up proc contains a HASPPARM DD Statement.
>
> I do not see one in your expanded JCL.
>
> //JES2 PROC N=SYS1,L=SHASLNKE,
> //  M=JES2PARM,PN=SYS1,PL=PARMLIB,U=
> //  PROC00='SYS1.PROCLIB',PROC01='SYS1.PROCLIB'
> //IEFPROC  EXEC PGM=HASJES20,TIME=1440,PARM=(WARM,NOREQ)
> //HASPLIST  *  DD DDNAME=IEFRDER
> //*
> //HASPPARM DD UNIT=,DSN=(),DISP=SHR
> //*
>
>
> Lizette
>
> --
> 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