Re: Cobol Install FS issue
Hello All,
I can clearly see all file systems are mounted correctly .
HFS 190 ACTIVE RDWR 03/06/2016 L=138
NAME=OMVS.MVS1.ZOS13.SIGYROOT23.40.14Q=138
PATH=/Service/usr/lpp/cobol
WhenI dont find any issue in filesystem mounted on this path, then what
else can be reason for this error while applying
BPXF140E RETURN CODE 0081, REASON CODE 0594003D. A LINK FAILED FOR
LINK NAME /Service/usr/lpp/cobol/../../demo/oosample/Check.j
Any more clue.
On Sun, Mar 13, 2016 at 5:47 AM, Lizette Koehler
wrote:
> Sorry if this has been discussed.
>
> Do a D OMVS,F on the system where the failure is occurring. If nothing
> pops out, open an SR with IBM
> Lizette
>
>
> -Original Message-
> >From: Mainframe Mainframe
> >Sent: Mar 11, 2016 8:16 PM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: Re: Cobol Install FS issue
> >
> >Thanks for reply. I am installing Cobol in new file system, I don't find
> >any issues with this directory structure. I tried all but not able to come
> >out with this issue.
> >
> >
> >BPXF140E RETURN CODE 0081, REASON CODE 0594003D. A LINK FAILED FOR
> >LINK NAME /Service/usr/lpp/cobol/../../demo/oosample/Check.j
> >
> >Any more suggestion.
> >
> >On Thu, Mar 10, 2016 at 4:29 PM, Giliad Wilf <
> >00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> On Thu, 10 Mar 2016 12:47:58 +0530, Mainframe Mainframe <
> >> mainframe1...@gmail.com> wrote:
> >>
> >> >Hello Group,
> >> > While installing Cobol 5.2, I am getting below issue.
> >> >
> >> >BPXF140E RETURN CODE 0081, REASON CODE 0594003D. A LINK FAILED FOR
> >> >LINK NAME /Service/usr/lpp/cobol/../../demo/oosample/Check.j
> >> >
> >> >I did check for all directory path and I don't find any issues with
> this.
> >> I
> >> >checked all available solution but nothing working for me.
> >> >
> >> >Any clue.
> >> >
> >> >--
> >> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >> - In order to maintain two different versions of Enterprise Cobol
> >> simultaneously, there is a requirement that each version
> >> has to have its own SIGYROOT filesystem.
> >> - When there is only a single version of Enterprise Cobol, its SIGYROOT
> >> gets mounted at '/usr/lpp/cobol/'.
> >> - What do we do if we have two or more?
> >> - The answer is you define two different mountpoints on top of
> >> '/usr/lpp/cobol/' and mount each Cobol's SIGYROOT at its own
> >> unique mountpoint.
> >> - Each Cobol will look for the DDDEF for SIGYHFS, which ends with
> >> '.../bin/IBM/', back two directory levels, and will expect
> >> its own SIGYROOT to have been mounted there, and will expect to see
> >> directories 'demo', 'include', and 'lib' alongside
> >> directory 'bin'.
> >> - Lookup the internet for a description of a technical problem, using
> >> "igzcjava.x" and BPXF140E as search arguments,
> >> e.g. http://www-01.ibm.com/support/docview.wss?uid=swg21195928
> >>
> >> We were installing Enterprise Cobol V4R2 for z/OS alongside existing
> >> Enterprise Cobol V3R4 for z/OS, and what I did was this:
> >>
> >> unmount filesystem('V3R4.SIGYROOT') immediate
> >> mkdir '/usr/lpp/cobol/EC34' mode(7,5,5)
> >> mkdir '/usr/lpp/cobol/EC42' mode(7,5,5)
> >> mount FILESYSTEM('V3R4.SIGYROOT') MOUNTPOINT('/usr/lpp/cobol/EC34')
> >> TYPE(HFS) MODE(RDWR)
> >> mount FILESYSTEM('V4R2.SIGYROOT') MOUNTPOINT('/usr/lpp/cobol/EC42')
> >> TYPE(HFS) MODE(RDWR)
> >>
> >> --
> >> 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: Cannot allocate Steplib?
Another little cutie that wiggled it's way in was CONCAT. For merging new DSNs to existing allocations. May have been on CBT first then some vendors started enhanced versions. In a message dated 3/13/2016 3:03:24 A.M. Central Daylight Time, eamacn...@yahoo.ca writes: about TSOLIB. It's been around a long time -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA7
Thanks Liz -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 13 March 2016 14:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA7 Yes. It is on communities.ca.com. Lizette -Original Message- >From: "Icke, Nick" >Sent: Mar 12, 2016 9:52 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: CA7 > >Hi > >Is there a listserv specifically dealing with Ca7 > >Regards > >Nick > >-- >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: Cannot allocate Steplib?
The only way STEPLIB can be allocated is in a PROC. Once you free it, you will have to re-logon to Re-allocate it. If you are using ISPF, you can use ISPLLIB. The downside is if you are mixing APF and NON-APF libraries You will lose authorization -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Finnell Sent: Sunday, March 13, 2016 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cannot allocate Steplib? Maybe that's why we got TSOLIB and ALTLIB for ISPF. Been so long, I wanna say mid eighties... In a message dated 3/13/2016 12:31:22 A.M. Central Standard Time, eamacn...@yahoo.ca writes: products that allow(ed) dynamic allocation of steplib, but you never could do it with raw (native) TSO. -- 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
IBM Systems Magazine article -- Learn by looking back
http://www.ibmsystemsmagmainframedigital.com/nxtbooks/ibmsystemsmag/mainframe_20160304/#/50 The Wayback Machine -- Archive.org -- remembers it all. Or at least a lot of it! I don't like most online magazine viewers but it seems the only way to see this article. -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cannot allocate Steplib?
On Sun, 13 Mar 2016 08:13:11 -0500, Peter Relson wrote: >>What happens if the program that employs such a product was fetched from a >>program object with the (newfangled?) deferred/incremental load protocol? > >This is only one of the reasons that reallocating STEPLIB (and perhaps any >other system-allocated DD) is not supported. >The operating system cannot prevent an authorized program from doing >whatever it wants, but you won't get any sympathy if something bad >happens. > >And of course in this case the system actually did prevent this specific >reallocation. The message seems pretty clear, as does the documentation >for the dynamic allocation code associated with the IKJ56236 message. > Thanks. Does the OS likewise prevent freeing and reallocating an active TASKLIB? The considerations seem similar. I suspect Lindy's requirement was overspecified. The real need may be not to reallocate STEPLIB but to execute a program from an arbitrary library, not necessarily in STEPLIB. But that facility is provided by ATTACH TASKLIB and TSO CALL (which I suspect uses a TASKLIB). But I wonder, what is the character of MVS programming that impels recurrent requests to reallocate STEPLIB rather than using those existing facilities, and entices various vendors to provide circumventions, however risky or restricted? (Well, the Rexx ATTCH* facilities, for example, have no TASKLIB option.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM RDEz
We do we installed in back when IBM first bought Rational and it was WSED then RDZ and a few names in between. Our developers like it we still haven't migrated after all these years into our change management tool. Not to say we can't but a lot of politics which will need to be worked out. The AD teams like it off shore and on shore. The new people who we hire right from school or intern programs like the ease of use. I'm old and still use ISPF and like it but when it comes to COBOL, JAVA etc RDZ is easy for use and deployment. Andy Does anyone's shop use RDz? Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cannot allocate Steplib?
On Sun, 13 Mar 2016 08:13:11 -0500, Peter Relson wrote: >If you don't like the STEPLIB that you're running with, then you ought to >design your application to run under a subtask that you can attach with a >TASKLIB that you open, so that module fetches will use the tasklib first. Or allocate some other DDNAME, open a DCB and pass that DCB to LOAD. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA7
Yes. It is on communities.ca.com. Lizette -Original Message- >From: "Icke, Nick" >Sent: Mar 12, 2016 9:52 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: CA7 > >Hi > >Is there a listserv specifically dealing with Ca7 > >Regards > >Nick > >-- >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: Cannot allocate Steplib?
>What happens if the program that employs such a product was fetched from a >program object with the (newfangled?) deferred/incremental load protocol? This is only one of the reasons that reallocating STEPLIB (and perhaps any other system-allocated DD) is not supported. The operating system cannot prevent an authorized program from doing whatever it wants, but you won't get any sympathy if something bad happens. And of course in this case the system actually did prevent this specific reallocation. The message seems pretty clear, as does the documentation for the dynamic allocation code associated with the IKJ56236 message. 0364 (868) Meaning: JOBLIB/STEPLIB specified as a ddname, or associated with specified dsname or pathname. These ddnames are allowed only for special data sets. The accompanying message IKJ56236I identifies which of the above ddname types is in error. (dsname allocation, ddname allocation, unallocation, concatenation, deconcatenation)(1) Application Programmer Action: Use a different ddname, or consult your system programmer for the proper ddname to use. Corresponding Message: IKJ56236I If you don't like the STEPLIB that you're running with, then you ought to design your application to run under a subtask that you can attach with a TASKLIB that you open, so that module fetches will use the tasklib first. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cannot allocate Steplib?
I saw some documentation, dated 1981, talking about TSOLIB. It's been around a long time. -teD Original Message From: Edward Finnell Sent: Sunday, March 13, 2016 03:25 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Cannot allocate Steplib? Maybe that's why we got TSOLIB and ALTLIB for ISPF. Been so long, I wanna say mid eighties... In a message dated 3/13/2016 12:31:22 A.M. Central Standard Time, eamacn...@yahoo.ca writes: products that allow(ed) dynamic allocation of steplib, but you never could do it with raw (native) TSO. -- 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
