Re: Question if COND code / IF THEN struct
---snip--- As a circumventive measure, one, less desirable choice, is to resort to either coding multiple PROC instances with specific check conditions or use JCL INCLUDE statements to externalize your individual PROC rqmt conditions and enclose the IF/THEN/ENDIF statements as needed for the first and subsequent PROC executions. ---snip--- Thanks for your detail explainlation! However, I don't understand how to use JCL INCLUDE statements to code the PROC requirement conditions AND being enclosed within the IF/THEN/ENDIF statements, can you kindly give me an example? by the way, it seems no easy to do so Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A few dumb USS questions
>> 1) The processes show as STC so I assume there must be JCL behind them? >Yes. The name is BPXAS. Actually, while this is undoubtably true, for all practical intents and purposes there is no JCL as we know it behind these 'address spaces with a number', even if they're considered 'STC' ny z/OS. You will need the D OMVS and F BPXOINIT commands to 'see' the connection (via asid) between the jobname and what USS cares about, the pid. And with the pid goes 'a command'. My favourite hate-application has about 65 address spaces, all with the same 'jobname' (other than the number for the fork()ed things) and the same userid. That's why they are so hard to control for an old-time z/OS sysprog. >3) Do/can USS processes run under JES control? (I assume not as we have >sometimes two or three processes with the same name which is a no-no in Z) As was stated before, the same jobname is NOT a no-no anymore. That restriction was lifted sometime in the nineties, for USS to work. I have a dim recollection that you could also run batch jobs with the same name simultaneously if some sort of parm is set *somewhere* (no clue where). Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OMVS data not found in dump
>Include OMVS and BPXOINIT in your jobname list and also
>DSPNAME=('OMVS'.*).
And before you do as Mark says, increase the size of your DUMPSRV
dataspaces, otherwise you end up with a partial dump. As of 1.10 (according
to the books) the default is still a meager 500M. When including OMVS
dataspaces, we need at least 6GB DUMPSRV dataspace to ensure a complete
dump.
Didn't I say in another post that all these newfangled USS applications are an
IBM joy to work with? Because IBM always has the 'the data are not in the
dump' excuse? And of course IBM software support NEVER tells you beforehand
what options to set (other then the often-copied sdump options that they
don't know *why* they specify them, either) or what address spaces to
include, not even when explicitly asked because the problem is very infrequent
and not reproducible at will. Sometimes software support even tells you 'data
are not in the dump' because they have no clue how to reset IPCS to another
address space.
Or Java is executing with an MQ bridge and a DB2 bridge in an IBM application
using LE and other OMVS services. And MQ software support insists on getting
MQ CHIN and MSTR included Ask me how I know. Don't ask me how I
reacted.
Barbara Nitz
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
GSIS vs IBM DB2s (part 2)
http://www.malaya.com.ph/jun29/edducky.htm GSIS vs. IBM, Round 2 IF you pay out P80 million for anything, you should have the right to expect that if something goes wrong with the damned thing the seller will try to help fix it, right? What you do not expect is that the bum who sold it to you will tell everyone within hearing distance that because he never told you to buy his product, he is not responsible for any problems that come your way from using it.That is exactly what is happening in the case of the Government Service Insurance System’s ongoing spat with the giant multinational International Business Machines (IBM) Corporation.GSIS, after being sold what it considers a "lemon" software by IBM Corporation, now finds itself at the receiving end of a lawsuit by the computer giant -- a case of offender having the gall to sue the aggrieved. IBM has chosen to sue the state pension fund instead of doing what it should have done -- fixing or replacing its faulty DB2 software which is, at the very least, partly – if not wholly -- responsible for fouling up a GSIS IT program.Sure, the GSIS was the first to file a case vs. IBM, but that damage suit was justified as a last recourse in the face of IBM’s intransigence and refusal to fix the problem. Questronix was the systems integrator that won the bid to implement the GSIS’s ILMAAAMS, (Integrated Loans, Membership, Acquired Assets and Accounts Management System) project of the agency. The project, which cost P80 million, involves developing the agency’s database for all its member services. (continued at URL... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The downside
One of the additional downsides is that you will consume slightly more MIPS (CPU), ceteris paribus. Or, said another way, z/OS 1.7 simply costs more to run than a newer release. Plus there's new function in each new releases, of course. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/390
Brian Westerman writes: >I think you might be able to run it under z/VM, you certainly >can run it under Hercules. If you get a fast enough PC, you >can probably beat the MIPS of what your running it on now;) OS/390 V1 is licensed software, and it is licensed to a specific machine. If the original poster wants to move OS/390 to another machine, he must seek IBM's permission. Permission will likely be granted for IBM, Fujitsu-Amdahl, and Hitachi hardware, new or used. It will likely not be granted for Hercules. The same is likely true for other vendor software (if any). Billy R. Bingham writes: >The company currently has a 2003-116 and IBM will be dropping >maintenance 12/31/2009. They want to go to newer hardware >(z890/z990) but does not want to upgrade their software, I >repeat, does not want to upgrade their software. They want >to stay on OS/390 1.3 until they migrate off to an ERP >package. Sorry, it is not technically possible to move to newer hardware and continue running OS/390 1.3. :-( OS/390 1.3 (IBM program number 5645-001) became generally available on March 28, 1997. Last order date for 1.3 was December 31, 1998. The Multiprise 2000 Model 116 (2003-116) was introduced in September, 1996. It is a one-way machine rated at 6 MSUs (Group 38) and about 38 MIPS. Assuming that machine configuration currently provides sufficient capacity, the most appropriate replacement models probably include the System z9 BC Model B01 (only 5 MSUs and about 38 MIPS) and the System z10 BC Model C01 (only 5 MSUs and about 38 MIPS). (The z10 would be preferable since it offers smaller capacity increments, along with other technology improvements.) Another possible option is the System z10 BC Model A02, a two-way machine with 6 MSUs and about 48 MIPS, if a two-way machine would be more appropriate. Let me give you some very rough and very quick information on monthly license charges. I cannot vouch completely for the accuracy here, but my numbers should be close. The Model 116 is a Group 38 machine, so I estimate that the U.S. monthly license charge for the base operating system (only) is $16,260. Full capacity licensing is required for OS/390. The System z9 or z10 models mentioned above, at 5 MSUs, would be eligible for Entry Workload License Charge (EWLC), and the charge for z/OS Version 1 (5694-A01) would be $4,403 per month for the base operating system, even at full capacity. (The company you are working with may find sub-capacity possible, depending on their current and projected utilization.) That's a 72.9% reduction in the monthly charge for the base operating system. As an aside: do you know if Oracle, Microsoft, or SAP has cut their prices by 72.9%? :-) Just for "fun," let's assume that the company had migrated to z/OS V1 five years ago. They would have saved $711,420 on the base operating system charge by now. That would have purchased some very nice hardware plus many hamburgers. There should also be an inflation adjustment here. The 2009 $4,403 monthly charge is actually equal to approximately $3,420 in 1998 dollars. With this inflation adjustment, the real reduction in price is just shy of 79%. Also, in that time the labor required to manage a mainframe has declined faster than for other platforms. If the 1998 fully burdened full time equivalent (FTE) employee cost was $150,000, today (with inflation) it would be just shy of $200,000. (Labor costs are quite regional, though, so YMMV.) There is also a substantial reduction in hardware maintenance charges, and the first year is under warranty. Methinks there was some grave mismanagement of IT infrastructure at this company. But it's not too late to correct that. To give yet one more data point, let's suppose you double the MSUs for z/OS. What's the price for incremental growth? Answer: $1,670. That is, you can increase z/OS capacity by 100% for 37.9% more software price. Of course, there's probably more on the machine than just base OS/390. There are no doubt various operating system features, plus middleware products. YMMV. Hope that helps. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A few dumb USS questions
On Sun, 28 Jun 2009, Rob Lister wrote: > > Because all the processes are started via appl mngmnt, when I added a > _BPX_JOBNAME to each startup script, this was ignored and the > _BPX_JOBNAME allocated to app mngmnt used for all subsequent processes. The RACF id under which the app mngmnt process is running must have at least READ access to the BPX.JOBNAME profile in the FACILITY class in RACF. If it doesn't, then the _BPX_JOBNAME is ignored. > > The Application Management task is obviously required for our application on > other platforms but I would have thought that on Z we already have > everything that our App mngmnt task does. If I was to remove app mngmnt, > could I sub JCL via OPC/TWS or by automation? Yes, I think so. You should really read up on JZOS and how it can be used in a batch job or STC. > > So here goes with a few Dumb questions: > > 1) The processes show as STC so I assume there must be JCL behind them? Yes. The name is BPXAS. This is a STC which works a lot like a JES managed initiator. That is, they are started and stopped "as needed". Basically when a fork() is done, an idle BPXAS is selected to run the UNIX program. If there is no idle BPXAS available, one is started if there are sufficient resources available (if not the fork() fails). A BPXAS "hang around" waiting for work for some period of time, then terminates if there isn't any. > > 2) If so, how can I see this JCL as looking via SDSF(PS) I see nothing. When > I > look at the startup process, all I see is a shell script? Trying to look at this is like trying to look at a JES initiator. Very difficult. > > 3) Do/can USS processes run under JES control? (I assume not as we have > sometimes two or three processes with the same name which is a no-no in Z) Yes, they do run under the primary JES. There is no restriction in z/OS about not having duplicate names with STCs. And, if you look at the newer parameters in JES2, you can even run batch jobs with duplicate jobnames now. > > 4) Can OPC/TWS sub/control tasks to USS? I don't know OPC/TWS. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: anynet SNA over TCPIP
On Sat, 27 Jun 2009 06:44:30 -0500, Chris Mason wrote: >... >[3] In principle this applies to APPN nodes also and could be used to >argue that, just because a LEN or APPN node does not have a "visible" >PU, it still has a PU and that the PU could be used to characterise the >type 2.1 node! Nobody has ever used that argument to refute my >insistence that there is no such animal as a "PU 2.1" and it may be >that you are the only person who can see the irony here - or indeed >follow what I am talking about! >... Well, I no longer have access to access to the SNA FAPs and can't find the equivalent APPN architecture definition so I don't know if there is any difference between the PUCP in a node type 2 and the PUCP in a node type 2.1. But in looking at a display of a "PU_T2.1" I see characteristics of the linkstation and maybe the node, but nothing I would associate with the PU. I think you might still be safe saying there is no such thing as a PU_T2.1. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question if COND code / IF THEN struct
On Sun, 28 Jun 2009 10:43:42 -0500, Scott Barry wrote: > >Oh well - another strike against JCL coding optimization attempts, while >having somewhat similar angst with "nested PROCs" to some degree, mostly >with restart/recovery attempts. > Have you ever suspected that IBM accepted a Requirement for nested PROCs in which the submitter had neglected to specify that all facilities available in first-level PROCs such as referbacks, overrides, and, yes, restart/recovery should equally be available in PROCs nested more deeply, perhaps assuming it was implicit? And IBM, seeing that it wasn't explicit, felt no responsibility to Do It Right and took all the shortcuts? Shame on IBM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Marty G Penhorwood/ISS/HQ/AGFin is out of the office. (returning 06/30/2009)
I am out of the office until 06/30/2009. I will respond to your message when I return. If you have a question that needs attention prior to that, please send to either Bill Wilfong or Dale Ennulat. Thank you. Note: This is an automated response to your message "IBM-MAIN Digest - 26 Jun 2009 to 27 Jun 2009 (#2009-178)" sent on 6/27/09 23:00:03. This is the only notification you will receive while this person is away. -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question if COND code / IF THEN struct
On Sun, 28 Jun 2009 01:56:59 -0500, Paul Ip wrote: >Hi all, > >If I have an JCL with an instream PROC: > >PROC1 PROC >PRCSTEP1 EXEC PGM=XXX >INPUT DD DSN=&FILE >PRCSTEP2 EXEC PGM=YYY >INPUT DD DSN=&FILE >PRCSTEP3 EXEC PGM=ZZZ >INPUT DD DSN=&FILE > PEND >STEP0001 EXEC PROC1,FILE=A1 >STEP0002 EXEC PROC1,FILE=A2 >STEP0003 EXEC PROC1,FILE=A3 >... >STEP000N EXEC PROC1,FILE=AN > >PRCSTEP1 will have an RC=0 >PRCSTEP2 will have an RC=16 (but not a failure case) >PRCSTEP3 will have an RC=0 > >My question is, how can I code the COND parameter or IF the ELSE on all >PRCSTEPs so that all the PRCSTEPs can be executed with previous >PROCSTEPs RC=0 *except* PRCSTEP2 can have a RC=0 to 16. >I have tried using "RC.PRCSTEP2 = 16" for IF then ELSE before PRCSTEP1 >(since STEP0002.PRCSTEP1 will be executed if RC<=16 of >STEP0001.PRCSTEP2). However it failed with JCL error since invaild referback. > >Please give me a hint, thanks! > >Paul A slight syntax correction with your post for IF/THEN/ENDIF - when specifying stepname/procstepname, the ".RC" follows. More to the point, yes, it would be useful to have the "RUN" condition not be so tight that it permits a "not yet declared" stepname/procstepname exactly for this purpose. As a circumventive measure, one, less desirable choice, is to resort to either coding multiple PROC instances with specific check conditions or use JCL INCLUDE statements to externalize your individual PROC rqmt conditions and enclose the IF/THEN/ENDIF statements as needed for the first and subsequent PROC executions. The interpreter is so tight that I was unable to use JCL SET symbolics with IF/THEN/ENDIF statements, attempting to set a "blank" SET symbol for the first execution of the PROC and follow that with another SET overriding the initial value to add the additional test after the first execution -- such as: // SET RUNCHECK= //PROC1PROC // IFRC = 0 &RUNCHECK THEN //PRCSTEP1 EXEC PGM=IKJEFT01,PARM=TIME //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY // ENDIF // IFRC = 0 &RUNCHECK THEN //PRCSTEP2 EXEC PGM=IKJEFT01,PARM=BOGUS //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY // ENDIF // IFRC = 0 &RUNCHECK THEN //PRCSTEP3 EXEC PGM=IKJEFT01,PARM=TIME //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY // ENDIF // PEND //STEP0001 EXEC PROC1 // SET RUNCHECK='OR (PRCSTEP2.RUN AND PRCSTEP2.RC LT 16)' //STEP0002 EXEC PROC1 //STEP0003 EXEC PROC1 Oh well - another strike against JCL coding optimization attempts, while having somewhat similar angst with "nested PROCs" to some degree, mostly with restart/recovery attempts. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A few dumb USS questions
I'm cross-posting to MVS-OE, a better source for this info. On Jun 28, 2009, at 05:44, Rob Lister wrote: Hi Folks, I am working for a company who are implementing a POSIX application on zOS and, as a zOS sysprog, I am struggling with a couple of issues. Whilst I am getting into the USS manuals, I thought I would see if anyone has already been through this pain and maybe get a few dumb questions answered before I go bog-eyed? I'm not slagging off USS as right now, I don't know enough to either praise or criticise it. It is just different to everything I have come across before in my insular,comfy and well worn slipper-like MVS career. Our application runs as 10 or more POSIX processes under USS. We use an Application Management task to start/stop and own the processes so our first address space is Appl Mgmnt and all subsequent processes assume this name via exporting a _BPX_JOBNAME parameter. Unfortunately, right now I don't seem to be able to get much further than all the processes taking the same name as exported via _BPX_JOBNAME associated with Appl mngmnt with 1,2,3,4, etc appended as a suffix. Whilst this an improvement on userid/suffix, it still doesn't allow me to identify the process via a useable name. What I'd like to see is each process be given a unique name to identify the actual process that is running. I can't even get this far. The command: u...@mvs:133$ for I in A B C D; do BPX_SHAREAS=NO _BPX_JOBNAME=JOB$I sleep 22 & done causes SDSF DA to show 4 processes as UserID + one character. Because all the processes are started via appl mngmnt, when I added a _BPX_JOBNAME to each startup script, this was ignored and the _BPX_JOBNAME allocated to app mngmnt used for all subsequent processes. The Application Management task is obviously required for our application on other platforms but I would have thought that on Z we already have everything that our App mngmnt task does. If I was to remove app mngmnt, could I sub JCL via OPC/TWS or by automation? So here goes with a few Dumb questions: 1) The processes show as STC so I assume there must be JCL behind them? 2) If so, how can I see this JCL as looking via SDSF(PS) I see nothing. When I look at the startup process, all I see is a shell script? The address spaces are created with job name BPXAS. Scan SYSLOG for: 08:17:33.95 STC08607 0281 $HASP100 BPXASON STCINRDR 08:17:34.00 STC08607 0281 $HASP373 BPXASSTARTED 08:17:34.02 STC08607 0090 IEF403I BPXAS - STARTED - TIME=08.17.34 08:17:34.02 STC08607 0290 BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB ... These are maintained with a HWM technique, so you won't see one for every fork() 3) Do/can USS processes run under JES control? (I assume not as we have sometimes two or three processes with the same name which is a no- no in Z) 4) Can OPC/TWS sub/control tasks to USS? I did warn you these were dumb questions but any/all ideas, tips, tricks and gotchas would be most welcome even if they are just pointing me to specific topics in the manuals. Many thanks to anyone inclined to respond. In the meantime, I will search the archives to see if any of these dumb questions have been answered before. Regards, Rob Lister Technical Consultant ACI Worldwide Limited -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
A few dumb USS questions
Hi Folks, I am working for a company who are implementing a POSIX application on zOS and, as a zOS sysprog, I am struggling with a couple of issues. Whilst I am getting into the USS manuals, I thought I would see if anyone has already been through this pain and maybe get a few dumb questions answered before I go bog-eyed? I'm not slagging off USS as right now, I don't know enough to either praise or criticise it. It is just different to everything I have come across before in my insular,comfy and well worn slipper-like MVS career. Our application runs as 10 or more POSIX processes under USS. We use an Application Management task to start/stop and own the processes so our first address space is Appl Mgmnt and all subsequent processes assume this name via exporting a _BPX_JOBNAME parameter. Unfortunately, right now I don't seem to be able to get much further than all the processes taking the same name as exported via _BPX_JOBNAME associated with Appl mngmnt with 1,2,3,4, etc appended as a suffix. Whilst this an improvement on userid/suffix, it still doesn't allow me to identify the process via a useable name. What I'd like to see is each process be given a unique name to identify the actual process that is running. Because all the processes are started via appl mngmnt, when I added a _BPX_JOBNAME to each startup script, this was ignored and the _BPX_JOBNAME allocated to app mngmnt used for all subsequent processes. The Application Management task is obviously required for our application on other platforms but I would have thought that on Z we already have everything that our App mngmnt task does. If I was to remove app mngmnt, could I sub JCL via OPC/TWS or by automation? So here goes with a few Dumb questions: 1) The processes show as STC so I assume there must be JCL behind them? 2) If so, how can I see this JCL as looking via SDSF(PS) I see nothing. When I look at the startup process, all I see is a shell script? 3) Do/can USS processes run under JES control? (I assume not as we have sometimes two or three processes with the same name which is a no-no in Z) 4) Can OPC/TWS sub/control tasks to USS? I did warn you these were dumb questions but any/all ideas, tips, tricks and gotchas would be most welcome even if they are just pointing me to specific topics in the manuals. Many thanks to anyone inclined to respond. In the meantime, I will search the archives to see if any of these dumb questions have been answered before. Regards, Rob Lister Technical Consultant ACI Worldwide Limited -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
