Re: Linklist load during IPL message
Hi Dave/All,
I completely agree with your opinions and I work to get the SMS
initialization before the DB2 stuff.
Thanks again for all.
On Wed, Oct 8, 2014 at 12:00 AM, Gibney, Dave gib...@wsu.edu wrote:
Still, why fight. The instructions to have SMS be the first subsystem up
are clear and only a couple decades old.
Your error shows that something was not as you and your IPL expected. This
may not fix the problem, but it will eliminate one possibility and doing it
correct may prevent other problems in the future.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Jake anderson
Sent: Tuesday, October 07, 2014 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linklist load during IPL message
Dave
Its a pds.
On 7 Oct 2014 23:53, Gibney, Dave gib...@wsu.edu wrote:
The SMS documentation clears says that SUBSYS SUBNAME(SMS)
INITRTN(IGDSSIIN) INITPARM('ID=00,PROMPT=DISPLAY') Should be the first
entry in IEFSSNxx and you don't seem to have it at all.
If SYSTEM.DB210.LINKLIST is a PDS/E, then that would be yet another
reason to be sure to have SMS initialized first.
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson
Sent: Tuesday, October 07, 2014 4:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linklist load during IPL message
Hi Peter/All,
I did :
SETPROG LNKLST TEST NAME(CURRENT) MOD(DSN3INI) CSV502I
MODULE
DSN3INI WAS LOCATED 715 IN DATA SET SYSTEM.DB210.LINKLIST USING
LNKLST SET CURRENT
SUBSYS SUBNAME(JES2) /* JES2 IS THE PRIMARY SUBSYSTEM */
PRIMARY(YES) START(NO)
SUBSYS SUBNAME(BLSR) /* BATCH LOCAL SHARED RESOURCES*/
INITRTN(CSRBISUB)
SUBSYS SUBNAME()
INITRTN(DSN3INI)
INITPARM('DSN3EPX,!,S')
The DB2 maintenance went on before the IPL, but not sure if some of
the
PTF
would have caused this problem.
On Tue, Oct 7, 2014 at 5:01 PM, Peter Relson rel...@us.ibm.com
wrote:
If you have not dynamically updated the LNKLST after IPL, then
probably the easiest thing to do is
SETPROG LNKLST TEST NAME(CURRENT) MOD().
Which will use the actual LNKLST DCB to search for . Given
the behavior cited, it likely won't be found. And there likely is
a message about the data set in question in the log.
Substitute LNKLST00 (or whatever was the IPL-time definition via
PROGxx) if you have dynamically updated the LNKLST.
I'm sure we all recognize that the phrase LINKLIST libraries are
loaded
from the OP is not really legit. The libraries themselves are not
loaded. Modules are loaded from the libraries (upon
request/demand).
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
-- For IBM-MAIN subscribe / signoff / archive access instructions,
send
email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
Peter, It would help if you replied and included the original posting. Sometimes people do not have time to find what was requested and it is helpful to include the posting. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, October 07, 2014 10:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Question on PER-SLIP and PRCNTLIM. No answer? Interesting! I was thinking this is one of the easier questions for the experienced debuggers on the list. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
It is NOT a percentage of capacity, it is a TIME based calculation, as in; not how much CP it is using, but how LONG it has been. I will admit that it is not very clear as to what the calculation is, but my first recommendation is to note in the PMR that it hit this limit and ask Level 2 a new value, they may have a better idea on what to specify, otherwise I would recommend doing it in increments, such as; PRCNTLIM=20, then PRCNTLIM=30, ... The manual says to avoid =99 because then there will be no limit. From the MVS Commands manual: PRCNTLIM=p For a PER trap, specifies a software limit for PER processing by indicating a maximum percentage of system time that can be devoted to processing caused by PER interruptions. At least 33.55 seconds must have elapsed since the first PER interruption before a trap will be disabled because of this limit. . . . The value computed to test PRCNTLIM is an approximation. SLIP makes this calculation only when a PER interrupt occurs, so the PRCNTLIM parameter does not cause the trap to be disabled until a PER interrupt occurs. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, October 07, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question on PER-SLIP and PRCNTLIM. We had to set an IF SLIP trap with JOBNAME= in support of a PMR. As I didn't specify PRCNTLIM, this was set to 10% by SLIP SET processing. The slip has been disabled due to PRCNTLIM before a dump was taken (DATA= wasn't fulfilled so far). I understand this to mean that the RANGE that is set produced that many PER interrupts, that slip processing was using more than the allowed 10% of system time and disabled the slip. What exactly does x% of system time mean? Is it a pecentage of the LPAR CP capacity? -- Peter Hunkeler -- 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: PSF OGL PPFA ACIF alternatives?
As long as they use Windows Metafile format and can print through the Windows print driver structure they'll work. LibreOffice Draw should work. Gimp would probably work as well, though business overlays are typically text and vector graphics rather than images, and for color printing its limited CMYK support may be a concern. Howard Turetzky Advanced Technical Support, Ricoh Production Print Solutions howard.turet...@ricoh-usa.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PSF OGL PPFA ACIF alternatives?
On Wed, 8 Oct 2014 09:30:21 -0500, Howard Turetzky wrote: As long as they use Windows Metafile format and can print through the Windows print driver structure they'll work. LibreOffice Draw should work. Gimp would probably work as well, though business overlays are typically text and vector graphics rather than images, and for color printing its limited CMYK support may be a concern. And I'll wonder about other platforms such as Linux and OS X. Some people prefer not to use Windows, and since price was mentioned, some people prefer not to pay for Windows. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] AW: Extensions (was: Interested in BASH ... )
On 2014-10-08, at 04:29, carr...@nationwide.com wrote: Some things I encounter is when i have developers working in OMVS the first thing they do is bring over their Linux or AIX scripts and they do not work. They try to use ksh or bash and can't so immediately we get a black eye for using such an old antiquated shell Users who don't comply with standards shouldn't expect portability. I'll attach some ls -lLi output that shows that several UNIX-like systems use dash: uname -a; ls -Lli `whence rexx regina` /bin/*sh | sort -nk 6,6 as an alias for /bin/sh. Dash is lightweight and POSIX-compliant with few extensions. This enforces that scripts that begin #!/bin/sh use dash, enforcing POSIX compliance. They also use dash as the interpreter for the system() function for reasons of performance. Ubuntu claims this significantly improves startup speed. On 2014-10-07, at 10:30, Mike Schwab wrote: If Bash was added to the POSIX standard, they would have to support it. No. It appears that having once qualified for UNIX branding, OMVS feels no need to comply with updates to the standard. Notable and annoying examples are the -L and -P options to cd and pwd, and that the default behavior of pwd is -P-like ratner than -L-like as POSIX requires. I hope not to see bash added to POSIX. Bash is bloatware; over twice as large as Rexx on most systems, and almost ten times as large as dash. Most installations of dash omit POSIX command line editing (it's an option), which I find annoying. But they expect dash not to be used as an interactive shell. I don't know how much command line editing would bloat dash. 502 $ uname -a; ls -Lli `whence rexx regina` /bin/*sh | sort -nk 6,6 Darwin PaulGilm.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 20905756 -rwxr-xr-x 1 root wheel53560 Oct 2 2010 /usr/bin/regina 8011852 -rwxr-xr-x 2 root wheel 767200 Feb 10 2010 /bin/csh 8011852 -rwxr-xr-x 2 root wheel 767200 Feb 10 2010 /bin/tcsh 8046173 -rwxr-xr-x 1 root wheel 1346544 Feb 4 2010 /bin/bash 8046219 -r-xr-xr-x 1 root wheel 1346624 Feb 4 2010 /bin/sh 6662774 -rwxr-xr-x 1 root wheel 1597200 May 11 2009 /bin/zsh 20905758 -rwxr-xr-x 1 root wheel 1866360 Oct 2 2010 /usr/bin/rexx 6661547 -r-xr-xr-x 1 root wheel 2186880 May 18 2009 /bin/ksh 503 $ uname -a; ls -Lli `whence rexx regina` /bin/*sh | sort -nk 6,6 Linux Linux-Mac 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:45 UTC 2014 i686 i686 i686 GNU/Linux 135180 -rwxr-xr-x 1 root root5436 Jun 30 2012 /usr/bin/regina 4909 -rwxr-xr-x 1 root root 112204 Feb 19 2014 /bin/dash 4909 -rwxr-xr-x 1 root root 112204 Feb 19 2014 /bin/sh 135165 -rwxr-xr-x 1 root root 403996 Jun 30 2012 /usr/bin/rexx 4824 -rwxr-xr-x 1 root root 986672 Sep 27 02:05 /bin/bash 4824 -rwxr-xr-x 1 root root 986672 Sep 27 02:05 /bin/rbash 50 -rwxr-xr-x 1 root root 1713424 Nov 14 2013 /bin/static-sh 507 $ uname -a; ls -Lli `whence rexx regina` /bin/*sh | sort -nk 6,6 Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux 4765 -rwxr-xr-x 1 root root 5544 Jul 11 2012 /usr/bin/regina 434 -rwxr-xr-x 1 root root 88340 Mar 29 2012 /bin/dash 434 -rwxr-xr-x 1 root root 88340 Mar 29 2012 /bin/sh 4758 -rwxr-xr-x 1 root root 342620 Jul 11 2012 /usr/bin/rexx 14879 -rwxr-xr-x 1 root root 813992 Sep 25 14:55 /bin/bash 14879 -rwxr-xr-x 1 root root 813992 Sep 25 14:55 /bin/rbash 512 $ uname -a; ls -Lli `whence rexx regina` /bin/*sh | sort -nk 6,6 Linux linaro-alip 3.0.57+ #26 PREEMPT Sun Mar 3 09:44:37 EST 2013 armv7l armv7l armv7l GNU/Linux 2358 -rwxr-xr-x 1 root root 5512 Dec 1 2011 /usr/bin/regina 14 -rwxr-xr-x 1 root root 63484 Mar 29 2012 /bin/dash 14 -rwxr-xr-x 1 root root 63484 Mar 29 2012 /bin/sh 276 -rwxr-xr-x 1 root root 77592 Dec 1 2011 /bin/posh 2221 -rwxr-xr-x 1 root root 252464 Dec 1 2011 /usr/bin/rexx 1767 -rwxr-xr-x 1 root root 605140 Sep 27 02:08 /bin/bash 1767 -rwxr-xr-x 1 root root 605140 Sep 27 02:08 /bin/rbash -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
Thanks, AL. I did read the manual, but unfortunately the description of PRCNTLIM is rather fuzzy (at least to me). It is NOT a percentage of capacity, it is a TIME based calculation, as in;not how much CP it is using, but how LONG it has been. It is a percentage value that is to be specified. How LONG... would be a time value. I imagine SLIP code somehow keeps track of how long it is active (processing PER events) and how long it is inactive (not processing PER events). This ratio is a percentage of time. I assume SLIP code runs disabled. So on an LPAR with only one CP, time is equally CPU time as well as wall clock time. (Can a logical CP running in disabled state become nondispatched by LPAR code?) If the LPAR has more than one CP, the HW might signal a PER event on more than one CP simultaneously. SLIP code would run on multiple CPs in parallel, probably serialized (true?). Either way, it would use CP capacity on each of the CPs. This is way I'm thinking PRCNTLIM is an LPAR capacity percentage. Since all of the above could be wrong (I'm only making assumptions, after all), it may well work completely different. I'm curious to understand this better. That's why I was asking. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Question on PER-SLIP and PRCNTLIM.
No answer? Interesting! I was thinking this is one of the easier questions for the experienced debuggers on the list. You would need access to the SLIP code to answer this question. I did look into this around 4 years ago, it just took me a while to find the notes from that investigation. The calculation is (((Amount of CPU time spent in PER on all CPUs since trap was enabled) / (number of CPUs online right now)) * 100) / (Elapsed time since trap was enabled) And yes, I know of several reasons why this may not produce the results you might expect, including 1. CPU online/offline reconfiguration 2. Doesn't normalize CPU time for subcapacity CPUs vs full speed specialty engines 3. Dividing by elapsed time, not CPU busy time Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Upgrade to Enterprise COBOL v5.1
On 10/8/2014 8:35 PM, Brian Peterson wrote: We have had a lot of success with COBOL 5 but have had a few edge cases where we've seen issues. Since you mention OPT(1), one thing we've seen with COBOL 5 is that the calling and called program parameter lists must be identical. Check and see if there is a coding mistake where your calling program specifies for example the 05 level of a data structure and the called program specifies the 01 level. We z/OS guys understand that it is just an address pointer, but the COBOL compiler will silently discard statements that are known to be a constant value since they cannot change. A statement cannot be 'a constant value'. A data item may be. 01 Field-01. 05 sub-field-02 pic x(8) value . 05 sub-field-03 pic x(8) value . If the calling program passes sub-field-02 to the called program instead of field-01, the compiler will assume the calling program cannot change sub-field-03 and drop for example IF statements that refer to sub-field-03 since the compiler knows what the value must be. That doesn't sound remotely accurate. Just because a field is initialized doesn't mean it cannot be changed; the compiler would not / could not arbitrarily drop data fields in parameter lists. I suggest the true cause of problems you encountered were caused by other reasons. Now, if a data item is not referenced in a program, the compiler has been known to remove the data item from a program under certain conditions. In your example, if no statement mentions any of the names Field-01, sub-field-02, or sub-field-03 then the structure might not be included in the object code at all. But that's not what you seem to be trying to say. -Steve Comstock Valid COBOL programs work well with COBOL 5 but edge cases can be tricky to debug. Another option is to try OPT(0). Brian -- 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: Upgrade to Enterprise COBOL v5.1
We seem to have hit a show stopper in our effort to implement COBOL v5.1 (upgrading from COBOL v4.2). A collection of nightly batch jobs incurs sporadic, seemingly random S0C4 abends when the main program and a couple of subroutines are compiled with the COBOL v5.1 compiler, with the rest of the subroutines compiled with COBOL v4.2 and/or COBOL v3.4. We've been working a PMR with IBM COBOL Support for a few months now, and IBM has identified the cause of the S0C4 as corruption of a pointer to a key LE control block. Current efforts are aimed at identifying the perpetrator of the corruption, but it seems we cannot obtain the problem documentation IBM has requested. Why not? you might ask. Well, first, the abends occur ONLY in Production. All efforts to recreate them in DEV have failed so far. Thus, setting up the capture environment in Production requires that we discuss its setup in Change Control each time, effectively limiting our attempts to once per week. Second, when one (or more) of the jobs incurs the S0C4, we set up a dynamic Storage Alteration SLIP with ACTION=TRACE and other parameters specified by COBOL Support, start GTF with TRACE=SLIP and re-run the job. Unfortunately, the job then runs to normal completion and no SLIP trace is captured. This has been true for each of multiple failed jobs that are re-run with the diagnostic capture set up. After all diagnostic capture attempts, the change package for the failing program is reverted to no COBOL v5.1- compiled components. Needless to say, we tend to get less enthusiastic about subsequent capture attempts. Environment: z/OS 1.13 on all LPARs, currently at identical maintenance levels (~RSU0514 plus HIPERs and PEFIXes through August); DB2 v10 in new function mode. DEV runs on a z114-N02; Production runs on a z114-Y02 (in case machine speed might be a factor); both CECs are at current and required MCL levels. Compiler options for COBOL v5.1 include ARCH(9), OPT(1) and TEST (EJPD,SOURCE). The batch jobs (31 total) in the collection are identical except for a warehouse identifier passed as a run-time parameter and are released to run concurrently. The load library is (required to be) a PDSE. Any ideas as to what else we might try would be appreciated, as would any ideas as to why only in Production? Regarding the latter, we've already dismissed planetary alignment, sunspot activity, moon phase, etc. :-) I reviewed your PMR and dumps, and made some suggestions in the PMR. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing VSAM Data from non-zOS platform
I think we can safely set aside all the file transfer options discussed in this thread as nonresponsive. The original poster specified there's a requirement for live/real-time data access -- that CICS TS, z/OS Batch, and Java programs must all concurrently read and update the VSAM-based data. Please don't recommend FTP for application integration purposes, at least as a general principle. Practically everybody who has ventured down that path is trying to remediate the resulting business problems. That warning aside, I've seen some good suggestions, and I'll elaborate on a couple of my favorites. The IBM software product's exact name is IBM InfoSphere Classic Federation Server for z/OS, and one of the functions it provides is JDBC access to VSAM data. You may also need VSAM RLS and/or Transactional VSAM (DFSMStvs) depending on how much true write/update concurrency you require and your circumstances. A really effective approach not yet mentioned is to simply run the Java in CICS Transaction Server for z/OS itself. CICS Transaction Server Version 5.1 and higher support the WebSphere Liberty Profile (WLP) as a standard feature at no additional charge, so moving the Java code to CICS TS has become rather easy. That Java code can then access VSAM directly and concurrently with non-Java programs running in CICS TS. It's also possible (and common), as another responder alluded to, to run a portion of the total Java code in question -- let's call that portion the data access objects -- in WLP within CICS TS, then run other Java components elsewhere if desired, and if there's merit. (You can often run all the Java in CICS TS itself.) If you don't have CICS Transaction Server Version 5.1 or higher yet, have a chat with IBM. One perfectly viable approach would be to run the current release of CICS Transaction Server initially only for the wonderful latest WLP functionality, leaving your other CICS regions at whatever release(s) they are (initially). You don't have to upgrade everything all at once -- or even anything, initially. (CICS TS is designed to interoperate between releases this way.) A Single Version Charge (SVC) period may apply (12 months), but talk with your friendly IBM representative about such issues if they exist. Yes, Java code running within CICS TS/WLP can access any JDBC-compliant database, including Oracle Database. I'm not sure why VSAM transparency into Datacom would be a common solution unless you happen to have Datacom, so I'm not sure where that idea came from. However, if you happen to have DB2 then IBM's CICS VSAM Transparency would provide the analogous approach. That is, you'd move at least the relevant data from VSAM into DB2 but use IBM CICS VSAM Transparency -- a product which doesn't actually require CICS, oddly enough -- to keep the applications that access VSAM data thinking they're still accessing VSAM as VSAM. DB2 is obviously then reachable via JDBC. You've also got the various access options via CICS TS, and CICS TS obviously knows how to access VSAM. Nowadays I would certainly have the JSON-related options on my short list, but there are many, many options. Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
