-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
On 7/30/2009 at 9:55 AM, in message
Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
If necessary, is there a way to inhibit
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
Great! First time ever! :-)
Well, almost: It's LNKAUTH=APFTAB rather than LNKAUTH=APFLIB. :-)
-jc-
Thanks,
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications
If necessary, is there a way to inhibit unauthorized individuals from linking
with AC=1, even when linking in to an authorized library?
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation
Lakewood, CO USA
P: 303-235-1403
F: 303-235-2075
: Wednesday, July 29, 2009 5:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Of link lists and application programs
..snip
I am confused as to what a source control management system has to do with
LNKLST. Can you elaborate?
Frank
--
NOTICE: This electronic mail message and any files transmitted
the modules with AC=1 (or greater)
Did I read or understand that documentation wrong?
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Wednesday, July 29, 2009 6:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Of link lists
On Wed, 29 Jul 2009 17:24:41 -0600 Frank Swarbrick
frank.swarbr...@efirstbank.com wrote:
:If necessary, is there a way to inhibit unauthorized individuals from linking
with AC=1, even when linking in to an authorized library?
Why would you allow them to update it at all? The linkage
If necessary, is there a way to inhibit unauthorized individuals from linking
with AC=1, even when linking in to an authorized library?
Procedurally, have your QA people do the final link into the production library.
-
Too busy driving to stop for gas!
List IBM-MAIN@bama.ua.edu
07/30/2009 09:45 AM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: Of link lists and application programs
From what I have read in documentation, it seems to me that even a
module linked AC=0 is still
: Of link lists and application programs
That is correct. A job step task is authorized (via the JSCBAUTH bit
being set in the JSCB) during initiation by the operating system if (and
only if) the following occur:
1 - All libraries in the TASKLIB or STEPLIB/JOBLIB concatenation are APF
authorized.
2
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
If necessary, is there a way to inhibit unauthorized individuals from
linking with AC=1, even when
linking in to an authorized library?
Why would an unauthorized individual be able to link anything
On 7/30/2009 at 7:04 AM, in message
f255efe0ecf08c4a9c1db6aff42354170bc0f...@ch2wpmail1.na.ds.ussco.com, Chase,
John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
Great! First time ever! :-)
Well, almost: It's
On 7/30/2009 at 8:30 AM, in message
1910aea19cd2554fb59403184ebe43810262fc3...@mmoexchmbs01.jhacorp.com, Hal
Merritt hmerr...@jackhenry.com wrote:
Many of us have to demonstrate a link between the source code and load
library. That is, we can identify which source code was used to create a
On 7/30/2009 at 9:55 AM, in message
f255efe0ecf08c4a9c1db6aff42354170bc10...@ch2wpmail1.na.ds.ussco.com, Chase,
John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
If necessary, is there a way to inhibit unauthorized
I'm looking for a way to scan the entire lnklst and find a particular
load module.
Ken Klein
Sr. Systems Programmer
Kentucky Farm Bureau Insurance - Louisville
kenneth.kl...@kyfb.com
502-495-5000 x7011
--
For IBM-MAIN
On Thu, 30 Jul 2009 12:31:10 -0400, Klein, Kenneth kenneth.kl...@kyfb.com
wrote:
I'm looking for a way to scan the entire lnklst and find a particular
load module.
Lots of ways. A couple:
ISRDDN (DDLIST command) that comes with your system.
Freeware, for example FINDMOD on my web site.
Mark
Mainframe Discussion List IBM-MAIN@bama.ua.edu
07/30/2009 11:31 AM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: Of link lists and application programs
I'm looking for a way to scan the entire lnklst and find a particular
load module
Perhaps not for long. The PCI screws seem to tighten every day.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Frank Swarbrick
Sent: Thursday, July 30, 2009 11:20 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Of link lists and application
On Thu, 30 Jul 2009 10:28:16 -0500, Wayne Driscoll wrote:
However, I will STRONGLY advise that ONLY programs designed to be run as
job step tasks (ie main programs) should be linked with AC=1 because if a
module that is designed to run as a subprogram gets linked with AC=1 it
could be possible
Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Zelden
Sent: Thursday, July 30, 2009 12:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Of link lists and application programs
On Thu, 30 Jul 2009 12:31:10 -0400, Klein, Kenneth
kenneth.kl...@kyfb.com
wrote:
I'm looking for a way
---snip-
I want to thank everyone who has chimed in on this.
It sounds like we need to use LNKAUTH=APFTAB instead of the default of
LNKAUTH=LNKLST so that our APPL libraries will not be APF authorized when
accessed via the
---snip-
When you're running real-time and any kind of outages or interruptions
cost a king's ransom per minute, you wait until business is ended Friday
before making updates. Saturday processing is basically the same as
weekday, but
Frank Swarbrick wrote:
If necessary, is there a way to inhibit unauthorized individuals from linking
with AC=1, even when linking in to an authorized library?
--
NO.
I STRONGLY recommend that you control who is
---snip-
From what I have read in documentation, it seems to me that even a
module linked AC=0 is still authorized if LINK/XCTLed from an authorized
library by a program that is AC=1 (or greater). So any program in a
Library that is APF
If necessary, is there a way to inhibit unauthorized individuals from linking
with AC=1, even when linking in to an authorized library?
If the calling module is AC=0, what does the rest matter.
Control the authorisation, and everything else falls into place.
-
Too busy driving to stop for gas!
I believe that you have mis-interpreted the doc.
As I recall, if an AC=1 program calls a AC=0 program, then AC=0 is set for the
entire task for its duration.
I thought so too.
But, if you start at 0, 1 never happens!
-
Too busy driving to stop for gas!
===
Rick Fochtman rfocht...@ync.net
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
07/30/2009 07:12 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: Of link lists and application programs
On Mon, 27 Jul 2009 08:27:38 -0500, Paul Gilmartin
paulgboul...@aim.com wrote:
...
o Does the OS hold LNKLST data sets open, thwarting reclaim
of PDSE unused space?
...
LLA and XCFAS on every LPAR in the Sysplex that has the dataset
in the LLA. Depending on how many LPARs have the dataset
I want to thank everyone who has chimed in on this.
It sounds like we need to use LNKAUTH=APFTAB instead of the default of
LNKAUTH=LNKLST so that our APPL libraries will not be APF authorized when
accessed via the LNKLST concatentation (or via a STEPLIB/JOBLIB for that
matter). We certainly
On 7/28/2009 at 4:34 PM, in message 4a6f7cf5.9030...@ync.net, Rick
Fochtman
rfocht...@ync.net wrote:
-snip--
Is PDSE your friend here?:
o Is LNKLST PDSE-friendly?
--unsnip-
-
Too busy driving to stop for gas!
-Original Message-
From: Frank Swarbrick frank.swarbr...@efirstbank.com
Date: Wed, 29 Jul 2009 16:15:29
To: IBM-MAIN@bama.ua.edu
Subject: Re: Of link lists and application programs
I want to thank everyone who has chimed
It sounds like we need to use LNKAUTH=APFTAB instead of the default of
LNKAUTH=LNKLST so that our APPL libraries will not be APF authorized when
accessed via the LNKLST concatentation (or via a STEPLIB/JOBLIB for that
matter). We certainly would not want this.
There are two criteria for a
Yes. You have it right.
Bob
Frank Swarbrick wrote:
I want to thank everyone who has chimed in on this.
It sounds like we need to use LNKAUTH=APFTAB instead of the default of
LNKAUTH=LNKLST so that our APPL libraries will not be APF authorized when
accessed via the LNKLST concatentation (or
Great! First time ever! :-)
Thanks,
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation
Lakewood, CO USA
P: 303-235-1403
F: 303-235-2075
On 7/29/2009 at 5:36 PM, in message 4a70dcf1.1030...@ix.netcom.com, Bob
Rutledge
(before taxes)
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Frank Swarbrick
Sent: Friday, July 24, 2009 6:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Of link lists and application programs
A little while ago I had posed a question about
-snip--
Is PDSE your friend here?:
o Is LNKLST PDSE-friendly?
--unsnip-
Not at IPL time. After IPL is complete, you could add it dynamically.
Not true for IPL time.
I was
Hi Rick,
When I worked in Iowa, I upgraded Changeman. Every release requires going
over all of your customization. I know I spent a lot of time figuring out
what had to change. Most of the changes were in ISPF datasets, especially
the skeletons. Since I had never worked with the product,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
[ snip ]
Systems is concerned about system integrity. Rightly so. LNKLST has
historically been for systems
libraries only. But since there is no similar facility for business
applications
snip
A little while ago I had posed a question about having applications
libraries in the system LNKLST. Some were for it, some were against it.
One of the prominent reasons for being against it was the need to do an
LLA refresh after implementing any changes to an application library. I
agreed
I can understand putting production level application load libraries
into LLA, but not development libraries.
In our shop, which is a very small one, refreshing the development
libraries every 15 minutes would be way too infrequent. In DB2
applications it would also cause abends unless you were
On Mon, 27 Jul 2009 07:43:23 -0500, Staller, Allan wrote:
A former employer of mine had user loadlibs in LLA (and I believe
lnklst). They were carried in a separate PROGxx member.
Every (in our case) 15 min, an F LLA,UPDATE=xx was issued by automation.
Not sure what they did when the applications
On Monday 27 July 2009 14:45, Staller, Allan wrote:
A little while ago I had posed a question about having applications
libraries in the system LNKLST. Some were for it, some were against it.
One of the prominent reasons for being against it was the need to do
an LLA refresh after
-snip--
Is PDSE your friend here?:
o Is LNKLST PDSE-friendly?
--unsnip-
Not at IPL time. After IPL is complete, you could add it dynamically.
Rick Fochtman pisze:
-snip--
Is PDSE your friend here?:
o Is LNKLST PDSE-friendly?
--unsnip-
Not at IPL time. After IPL is complete, you could add it dynamically.
Not true for IPL
On Fri, 24 Jul 2009 17:30:23 -0600, Frank Swarbrick
frank.swarbr...@efirstbank.com wrote:
snip
From my perspective this works exactly as I, an applications developer,
desire. It has neither the advantages nor the disadvantages of LLA
controlled libraries. I am fine with this.
Systems is
A little while ago I had posed a question about having applications libraries
in the system LNKLST. Some were for it, some were against it. One of the
prominent reasons for being against it was the need to do an LLA refresh after
implementing any changes to an application library. I agreed
Frank Swarbrick wrote:
snip
Systems is concerned about system integrity. Rightly so. LNKLST has
historically been for systems libraries only. But since there is no similar
facility for business applications libraries this seems to be the only way I
can get what I want. In any case, does
Which is what is concerning/confusing. We have this:
LNKAUTH=LNKLST
And yet according to those displays I did the three APPL libraries, and some
others as well, are not APF authorized.
Explanation?
Thanks,
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
LNKAUTH=LNKLST only _treats_ unauthorized libraries as authorized when programs
in them are accessed via the link list. Otherwise, they are not authorized (not
known to APF) and so don't show up in the displays.
The integrity issue that concerns your systems folks remains.
Bob
Frank
48 matches
Mail list logo
