SIGNOFF IBM-MAIN
Thanks for all the fish! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I knew Cobol 6.3 takes more resources to compile than 4.2 but should I be concerned about how much?
Your issue does seem a bit out of the ordinary - it might be a problem. If you have the time, you could open a ticket with IBM. At our shop, we had a COBOL program that took 62 minutes to compile. I reported it to IBM and their initial reaction was that they thought that might be okay. But they eventually reviewed the program and issued a fix. Regards, Greg Shirey Ben E. Keith Co. -Original Message- From: Jantje. Sent: Tuesday, April 19, 2022 4:19 AM On Mon, 18 Apr 2022 20:18:18 +, Pommier, Rex wrote: >Hi list, > >Should I be concerned about the amount of resources Cobol 6.3 is occasionally >using as compared to 4.2? No. But you have to cater for the requirements... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding an Archive volume to the pool
It's Greg, by the way.With more information, I see that you are indeed trying to extend the candidate volumes for a data set. The message below indicates it is not a VSAM file, is that right? If so, is it SMS-managed? If not, I'm afraid the issue is fairly clear: Restriction: This does not work with non-SMS non-VSAM. If it is SMS-managed, the manual indicates that you can only add nonspecific volumes to non-VSAM data sets, that is, ADDVOLUMES(* * * * * * * *) to add 8 candidate volumes. However, my experiments issuing the command with a specific volser did not generate the same message as you received, so I'm not sure that's your issue. More information here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/da6i2056.htm Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Watkins, Philip S. Sent: Friday, March 30, 2018 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Adding an Archive volume to the pool Thanks for responding Shirley. I am new to this, but we have a pool of archive packs 3390-9's which have been added to the catalog below. I am simply trying to add 8 more volumes to the pool hopefully without deleting and redefining the catalog. FDRABR.POOLDISK.ARCHIVE1 AR2330+ All allocated volumes: More: + Number of volumes allocated: 14 AR2330 AR2331 AR2332 AR2333 AR2334 AR2335 AR2336 AR2337 AR2340 AR2341 AR2342 AR2343 AR2344 AR2345 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Thursday, March 29, 2018 4:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Adding an Archive volume to the pool Philip, I believe the example you posted below is attempting to add a candidate volume to the catalog for the data set FDRABR.POOLDISK.ARCHIVE1.If you are trying to add a volume to a storage pool, I think you'll need to go through the ISMF panels. (Unless this is something specific to FDR, which I know nothing about... ) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Watkins, Philip S. Sent: Thursday, March 29, 2018 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Adding an Archive volume to the pool Hey Guys, I am trying to add new DASD volumes to our existing archive pool using IDCAMS and I am getting an VSAM error. RETURN CODE 48 Explanation: Incorrect catalog function. Reason Code Description x Explanation: An internal logic error has occurred. Programmer Response: Contact the IBM Support Center. 6 Explanation: An ALTER of a non-VSAM entry is not allowed for the fields being modified. Programmer Response: Ensure that the proper entry name was specified on the access method services ALTER command and that only fields that exist for a non-VSAM entry are requested to be changed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding an Archive volume to the pool
Philip, I believe the example you posted below is attempting to add a candidate volume to the catalog for the data set FDRABR.POOLDISK.ARCHIVE1.If you are trying to add a volume to a storage pool, I think you'll need to go through the ISMF panels. (Unless this is something specific to FDR, which I know nothing about... ) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Watkins, Philip S. Sent: Thursday, March 29, 2018 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Adding an Archive volume to the pool Hey Guys, I am trying to add new DASD volumes to our existing archive pool using IDCAMS and I am getting an VSAM error. RETURN CODE 48 Explanation: Incorrect catalog function. Reason Code Description x Explanation: An internal logic error has occurred. Programmer Response: Contact the IBM Support Center. 6 Explanation: An ALTER of a non-VSAM entry is not allowed for the fields being modified. Programmer Response: Ensure that the proper entry name was specified on the access method services ALTER command and that only fields that exist for a non-VSAM entry are requested to be changed. //ADDVOL EXEC PGM=IDCAMS,REGION=512K //SYSPRINT DD SYSOUT=* //SYSINDD * ALTER - FDRABR.POOLDISK.ARCHIVE1 - ADDVOLUMES(AR2338) LISTC - ENT(FDRABR.POOLDISK.ARCHIVE1) VOL IDCAMS SYSTEM SERVICES TIME: ALTER - FDRABR.POOLDISK.ARCHIVE1 - ADDVOLUMES(AR2338) IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 48 - REASON CODE IS IGG0CLE8-6 IDC0532I **ENTRY FDRABR.POOLDISK.ARCHIVE1 NOT ALTERED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FDRMOVE sample jcl
Actually, DFSMSdss appears as a line item on my monthly IBM invoice. I believe it is DFSMSdfp that is the base part - the "free product" as it were. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, March 5, 2018 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FDRMOVE sample jcl HSM and RMM are other payable products/services under the DF/SMS service, but DF/DSS 'data set services' are not payable services or product, its part of the base or base + features. Carmen Vitullo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS STORGRP question
Defining a storage group as OVERFLOW provides most of that function by default. I believe the difference is that QUINEW volumes are used as a "last resort" whereas OVERFLOW volumes are used when the high threshold will be exceeded. >From "defining storage group attributes" in the Knowledge Center: If all volumes in a non-overflow storage group are so full that the current allocation request will push them over high threshold, while volumes in the overflow storage group are not so full, then the new data set will be allocated on a volume in the overflow storage group. The assumption is that all other attributes of the non-overflow storage group and overflow storage group and the volumes in those storage groups are the same Volumes residing in overflow storage groups are preferred over quiesced volumes and storage groups. If you quiesce an overflow storage group or volume then the quiesced volumes are preferred over quiesced overflow volumes. Regards, Greg Shirey Ben E. Keith Company From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Schroeder, Wayne Sent: Tuesday, April 25, 2017 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS STORGRP question Hey Jesse, I have the same setup but I have my OVERFLOW volumes set as QUINEW so they are only used if the original SG can't hold all of the data. Hope this helps. Wayne Schroeder Mainframe Storage Administrator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Loyalty
With apologies to Firesign Theater, but that's an insane question to ask, man, how can we know what you read? Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 13, 2017 9:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Loyalty Was it here, or somewhere else, that I read something like "Long term planning is a waste of time. The society and technology is simply changing too fast for the historical '5 year plan'." 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: HSM followup question
I could be wrong, but I believe the point being made was that the Management Class assignment could be driven by the values of Data Class or Storage Class, but not Storage Group. On the other hand, there are a lot of factors that can drive an MC assignment in addition to or in place of the DC or SC values. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Sunday, February 05, 2017 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM followup question > Based on this, MC can only set three ways: By DC, by SC or by the MC routine > itself. Is this true now? It used to be that only the corresponding ACS routine could set a class. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP018I THREAD ENDED WITHOUT BEING UNDUBBED WITH COMPLETION CODE 0033E000 , AND REASON CODE 00000000
A quick search of the archives reveals that this question has been asked several times over the years. Here is a reply from Shmuel in 2006: >BPXP018I THREAD 0DDE1400, IN PROCESS 16777595, ENDED WITHOUT >BEING UNDUBBED WITH COMPLETION CODE 0033E000, >AND REASON CODE . Sounds like CICS is doing a DETACH for a task that hasn't had time to shut down cleanly. Shmuel (Seymour J.) Metz, SysProg and JOAT Reference: https://listserv.ua.edu/cgi-bin/wa?A2=ind0608=IBM-MAIN=R45915 Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Mattson Sent: Thursday, January 19, 2017 3:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BPXP018I THREAD ENDED WITHOUT BEING UNDUBBED WITH COMPLETION CODE 0033E000 , AND REASON CODE Going to CICS TS 5.2 and noticed this message when the CICS region comes down. zOS 1.13 DB2 and IMS It looks like OMVS is FULL ACTIVE. So why getting this message when CICS Region comes down? +DFHTM1703 TCICS01 CICS is being terminated by userid CICSMTO in transaction CESD. BPXP018I THREAD 0D8D8B00, IN PROCESS 124, ENDED WITHOUT BEING UNDUBBED WITH COMPLETION CODE 0033E000 , AND REASON CODE . "D OMVS" gives BPXO042I 12.59.18 DISPLAY OMVS 904 OMVS 000E ACTIVE OMVS=(00) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSS or RACF case sensitive
Which the f part are you questioning? HELLO is an invalid keyword, so enter something valid: Send Hello user(*) IKJ56700A ENTER MESSAGE TEXT ENCLOSED IN APOSTROPHES - 'Hello' IKJ56712I INVALID KEYWORD, HELLO IKJ56703A REENTER THIS OPERAND - user(*) Hello DPC088 *** Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, December 23, 2016 2:58 PM And here, I discover another TSO idiocy: send Hello user(*) IKJ56700A ENTER MESSAGE TEXT ENCLOSED IN APOSTROPHES - 'Hello' IKJ56712I INVALID KEYWORD, HELLO IKJ56703A REENTER THIS OPERAND - wtf!? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER SYSIN Comments?
Yes, it was a serious question. Sorry for bothering you with my unimaginative inquiry. We can't all be as smart as you... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 20, 2016 10:52 AM On 2016-12-20, at 09:34, Greg Shirey wrote: > I hesitate to ask, but how are you using IEBGENER without JCL? > Is that a serious question? Use your imagination. I suppose, in extreme pedantry there's always JCL. In TSO, there's the LOGON Proc; In UNIX, there's BPXAS. But neither of those gives me much opportunity to insert comments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER SYSIN Comments?
I hesitate to ask, but how are you using IEBGENER without JCL? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 20, 2016 9:53 AM On Mon, 19 Dec 2016 23:30:00 -0600, Elardus Engelbrecht wrote: > >I'm just curious - why not put comments in JCL if you can not put it in SYSIN? > What if there's no JCL? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A true discussion in today's world (at least here)
Personally, I think the analogy is quite appropriate and I appreciate Skip sharing it. I’m sure most analogies, “in some circumstances” can be proven to fail, but car maintenance is a fairly typical consideration for most people in the US. If you live in an area with a dense population that mostly relies on public transportation, then modify the analogy to the subway system or the busses, or point to the Alaska Airlines wiki article to show the dangers of delaying maintenance. My 2 cents, Greg Shirey Ben E. Keith Company From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, November 23, 2016 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: A true discussion in today's world (at least here) On 23 November 2016 at 12:33, Jesse 1 Robinson <jesse1.robin...@sce.com<mailto:jesse1.robin...@sce.com>> wrote: > When I get flak about the churn of staying current with maintenance, I climb > my soapbox. Look, I say, I've calculated that on balance it's cheaper to > drive your car as long as it runs rather than take in for periodic > maintenance, which is both time consuming and out-of-pocket costly. Most > likely it will fail somewhere down the road ;-) but getting it fixed then > will be cheaper and quicker overall. > > Well, I say, if you wouldn't think of managing your car that way, why would > you think it makes sense for a computer system? The analogy is cute, but I think it fails The problem is that in some circumstances that's a perfectly reasonable way to manage a car. Depending on the age, how much you depend on it, whether you ever drive a significant distance from home, etc. etc. there may be nothing wrong with deferring or not doing some maintenance. I live in a city, mostly walk or use transit, and I have very little need for reliability in a car. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Randomly disappearing IGD101I messages.
Peter, All new allocations are not necessarily seen by ACS routines. It depends on your authority. >From DFSMSdss Storage Administration Reference: http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/dgt3u2150.htm BYPASSACS specifies that Automatic Class Selection (ACS) routines are not to be invoked to determine the target data set's storage class or management class names. To specify BYPASSACS, RACF(r) authorization might be required. I posted an example earlier in this thread. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Thursday, October 20, 2016 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Randomly disappearing IGD101I messages. All new allocations are seen by SMS's ACS routines. If they decide to assign a Storage Class to the data set, then the data set is "SMS managed"; if not then not. Does anyonw know it it is possible to "bypass the ACS routines" for new alloctions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Randomly disappearing IGD101I messages.
Kees, Yes, running the same job, but removing the BYPASSACS parm results in the SMS-managed data set being created, but there is still no IGD101I message. That's interesting. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Thursday, October 20, 2016 2:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Randomly disappearing IGD101I messages. Greg, If you request to bypass SMS, no IGD101I can be expected. Can you create an example where things are left to SMS when possible? Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Randomly disappearing IGD101I messages.
Here is a job which produced a new SMS-managed data set without generating an
IGD101I message:
//DPC088X JOB 111,NOTIFY=DPC088,CLASS=A,MSGLEVEL=(1,1)
//STEP01 EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD SYSOUT=*
//DD2 DD UNIT=3390,VOL=SER=TSO003,DISP=SHR
//SYSIN DD *
COPY ODD(DD2) -
DS(INCLUDE('DPC088.DISK.PTF')) -
BYPASSACS('DPC088.DISK.PTF') -
RENAMEU((DPC088.DISK.PTF,SYT.DPC088.DISK.PTF)) -
STORCLAS(TSOSC) -
DELETE PURGE CATALOG PROCESS(SYS1) ALLDATA(*)
Regards,
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Thursday, October 20, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.
"So, it is DMS or FDR which decide whether to place those IGD* messages or not."
To be precise:
It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby
causing the IGD message to appear or not.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Randomly disappearing IGD101I messages.
I would suggest asking CA about the DMS step not generating the IGD101I message. (DMS has a "hook" in SMS, doesn't it?) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, October 18, 2016 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Randomly disappearing IGD101I messages. One I see BMC has asked for doc. I would definitely do that. Two, I concur with Tom Conley, Most scheduling software will provide an SMF Exit in order to see when datasets are created/updated. I would follow up with BMC and see what they say. If they are dependent on IGD101I then you need to open a case to IBM on how or when the IGD101I is produced to SYSLOG. A message is produced or not based on MPF list, Automation Tools, or a user exit. The Vendors (IBM and BMC) should be able to help you determine why this is going on. What z/OS Maintenance has been implemented when you first noticed this issue What BMC maintenance has been implemented when you first noticed this issue What user exits are in your system (IEF*) or MPF List exit, or Automation tool changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Randomly disappearing IGD101I messages.
Kees, How are you verifying the data set was created? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Tuesday, October 18, 2016 6:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Randomly disappearing IGD101I messages. No, everything is equal in all jobs (from what I could check), except the appearance 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: SMS Volume Status
Does this command give you want you're looking for? I can't test it because I don't have a STORGRP with volumes in a different status, but it does list the status of each volume in the group - if they aren't all the same that should be some kind of indication of difference. D SMS,STORGRP(sgname),LISTVOL Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chuck Kreiter Sent: Wednesday, October 12, 2016 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS Volume Status I'm looking for a way to identify volumes in a SMS storage group that have a different status than what was defined in the storage group (i.e. volumes that are enabled in the storage group that are currently DISNEW because a vary command was issued). Anyone know of a way to identify this? Thanks. -- 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: RACF LISTDSD oddity
No worries. Sorry I wasn't clearer the first time. Byproduct of trying to write too quickly, I'm afraid. Regards, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 11, 2016 5:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF LISTDSD oddity With egg on face, I misread the string every time. Other guy fixed his command; it works. Thanks and apologies. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, October 11, 2016 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF LISTDSD oddity Skip, I'm suggesting that he's entering the wrong command - LISTDS instead of LISTDSD. Regards, Greg Shirey Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF LISTDSD oddity
Skip, I'm suggesting that he's entering the wrong command - LISTDS instead of LISTDSD. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 11, 2016 5:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF LISTDSD oddity Answering multiple questions. PROFILE -- I have PREFIX set, but the command works for me without prepending my prefix. WAD -- If you do TSO H LISTDSD SYN you will see that the keyword PREFIX() is a valid filter. For me it's being interpreted that way; for the other guy it's ignoring '(ABC)' altogether and treating the keyword as a data set value. We are logged on to the same system @ 2.1. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF LISTDSD oddity
That's the message you get if you issue [tso] LISTDS PREFIX(ABC). At least that's what I got. LISTDSD works as intended Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 11, 2016 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF LISTDSD oddity (I know, should go to RACF List.) A user wants to list RACF profiles for all data sets beginning ABC. So I did this: [tso] LISTDSD PREFIX(ABC) I got a list of all profiles beginning ABC. When he did exactly the same thing, he got this: DATA SET userid.PREFIX NOT IN CATALOG We both have RACF AUDIT authority and nothing else. Say what? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com<mailto:robin...@sce.com> -- 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: VSAM CA reclaim for RMM
Skip, The IGDSMSxx setting is either NONE or DATACLAS. So, it's not quite global - the VSAM file must be assigned a DATACLAS at creation which has CA RECLAIM set to Y. We modified all our Data Classes sometime in mid-2012, so our SMS-managed VSAM files have been reclaiming CA's for years. I spent a lot of time trying to determine a method of proving any benefit or detriment but never could. Sorry to be late joining the thread, been out for a few days... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: Jesse 1 Robinson [mailto:jesse1.robin...@sce.com] Sent: Thursday, September 29, 2016 4:03 PM Subject: Re: VSAM CA reclaim for RMM Correcting ALTER syntax. -Original Message- From: Jesse 1 Robinson Sent: Thursday, September 29, 2016 1:59 PM To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: VSAM CA reclaim for RMM Thanks. Spent some time this morning wading through the doc. Here's a thumbnail version of my understanding. -- CA reclaim must be 'turned on' at the system level in PARMLIB IGDSMSxx. Default value is 'off'. -- It can also be turned on or off for a system with a SETSMS command. -- Once turned on globally, CA reclaim will be in effect for (more or less) every VSAM cluster unless a cluster is specifically turned off. That is, the default at the cluster level is on. My RMM control data set is 'on' as shown by LISTCAT. -- You can turn a cluster off or back on with a simple ALTER command--which BTW I cannot find documented anywhere except in KC discussions of CA reclaim. For example, I cannot find any reference to reclaim in TSO HELP for ALTER. -- The IDCAMS command is "ALTER entry-name RECLAIMCA/NORECLAIMCA". That command is accepted now when I enter it even though we do not have reclaim turned on globally. So if you turned reclaim on for 'some user catalogs' and for SMS control data sets, did you take any action to turn it off for everything else in the house? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com > When CA reclaim was first presented at a closed SHARE session on a Sunday > morning, there was great interest in the room but also some skepticism. What > is the current consensus on CA reclaim? How extensively is it implemented > these days? Recommendations? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Automation Question
John, Wouldn't you have to reverse step 2 and step 1 of your job? I don't think you could rename SOME.PDS.LOADLIB if the STC were still running. (Data set in use) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Saturday, September 10, 2016 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: System Automation Question Sounds pretty decent to me. I might do it slightly differently. 1) FTP the new loadlib to z/OS with a new name (say SOME.PDS.LOADLIB.NEW) 2) FTP a z/OS job which does two things: 2a) Issues a F MODIFY,stcname,STOP (or whatever) 2b) submits a new job. 3) The job submitted by the the FTP'd job does: Job 3 step 1 - IDCAMS to delete SOME.PDS.LOADLIB.OLD, rename SOME.PDS.LOADLIB to SOME.PDS.LOADLIB.OLD rename SOME.PDS.LOADLIB.NEW to SOME.PDS.LOADLIB Job 3 step 2 - IEFBR14 allocation SOME.PDS.LOADLIB with DISP=OLD to stop job from running until STC shuts down (enq conflict) job 3 step 3 - issue S STC to restart the STC - however it is you issue z/OS commands within a z/OS jobstream But not with a /*$VS,'S STC' in the job's JCL since that runs too soon This avoids your step #2 of "wait for the STC to terminate" because the job mentioned in my step 3 won't really start until the STC is down. I think this would be easier to accomplish since you can't really "wait until STC is down" in some manner without some outside (non z/OS standard) software. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change RC in compilation step
Jorge, I believe the V4R2 version of the message was IGYOP3091W, which is also a warning message and would have also generated an RC=04. The compiler may be incorrectly indicating code has been discarded - see APAR PI63119, for instance. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jorge Garcia Sent: Friday, August 26, 2016 1:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Change RC in compilation step Hi all, We've just upgraded to Cobol V5R1 and in the new versión appears a new warning message "IGYCB7300-W The code from lines in program 'xx' can never be executed and was therefore discarded". This message doesn't appear in V4R2, now the compilation step finishs with RC=04 and the job cancels. Does exist any option to change the RC with this warning from RC=04 to RC=00?. It would be a workaround meanwhile we correct all the programs affected. Regards Jorge Garcia Juanino Gerente sistemas z/OS ACTP – DIAC – Operación y Soporte EMEA MAPFRE Avenida del Talgo 100-103 – 3ª Planta CP 28023 Madrid Tel. 91 581 27 34, Movil 618333559 jgarc...@mapfre.com -- 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: DFHSM CDS backup versions
As far as HSM and RMM "talking" to each other, there is this, from the RMM Implementation and Customization Guide, I think for version 1.13: You can use the TVEXTPURGE parmlib option in the DFSMSrmm EDGRMMxx parmlib member to control the action DFSMSrmm takes when DFSMShsm calls EDGTVEXT. A benefit of this interaction is that DFSMSrmm can prevent DFSMShsm from overwriting its own control data set backup, automatic dump, ABARS, and copies of backup or migration tapes. Although DFSMShsm checks its own migration and its own backup tapes, DFSMSrmm checks them as well. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vince Getgood Sent: Thursday, July 07, 2016 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM CDS backup versions All, Thanks for the hep so far. Please bear in mind that I "inherited" this site from another contractor, and have no documentation about what was done or why. He set this up. I also have no prior experience with RMM. Try changing the "count" in the VRS to a "more reasonable (FSVO reasonable) value. e.g. 10 and see if the tapes release. I'll try that, thanks. HSM and RMM are independent products. Some shops use RMM with FDR instead of HSM. Others use HSM with CA-1 instead of RMM. The two products will not talk to each other unless you tell them to. I can't find anything in the RMM or HSM manuals that tells me how to make them "talk" to each other. HSM is definitely releasing migration and backup tapes, just not CDS backup tapes. RMM talks about defining HSM to RACF, and setting RMM & HSM options (which as far as I can tell has all been done). The only inconsistency I can see is that the RMM manual says to code SETSYS TAPESECURITY(EXPIRATION), and we have SETSYS TAPESECURITY(RACF). If you can point me at the relevant part of the manual, I'll happily read 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: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Willie has already posted that there is no backup. The data set along with the catalog entry has been deleted - as long as the ML2 tape has not been recycled, it can be retrieved from there. There is a documented procedure for doing this in the HSM administration manual. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walter Davies Sent: Monday, June 20, 2016 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME Just because you delete a data set if it has backups they might still be there. Try allocating the old DSN as empty and restore from a backup. I have done that before. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
In the z/OS 1.13 DFSMShsm Storage Admin manual, there is a page titled: 1.20.9 Case 9: Reestablish access to previously deleted migrated data sets (no backup exists, ML2 only) Here is a link: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s6a2/1.20.9?SHELF=ALL13BE9=20120808094757 Back when I worked at a shop that had HSM, I had to use this procedure several times. I would assume it is still valid. Note, however, that the last step reads: " If you follow all steps correctly and you are still unable to recall the data set, contact IBM Support." Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, June 20, 2016 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME If the problem is the dataset was just plain deleted and there is no longer a catalog entry, you need to find a full volume or other DR volume backup for recovery. DFHSM will have nothing available to you. If there is anything left in DFHSM, then either a product like VANTAGE with the DFHSM function included could help. Otherwise contact IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is format of Job ID documented?
The JES2 Init & Tuna reference notes this in the description of the RANGE initialization statement: RANGE=n[,m]|1, Specifies the range of numbers (1 through 99) which JES2 will assign as JOBIDs to jobs which originated on the local node. The integer n specifies the lowest number (1 through 99) which will be assigned as a JES2 job identifier for jobs originating locally. The integer m specifies the highest number (n+10 through 99) which will be assigned as a JES2 job identifier to jobs originating locally. Note that setting the upper limit above 99,999 will cause the JOBID format to change from CCCN to C0NN where CCC is either JOB, STC, or TSU, and C is J, S, or T. N or NN is a number. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa400/has2u600110.htm Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, June 15, 2016 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where is format of Job ID documented? Thanks. Supports the idea of only three possible prefixes. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine the PDS a job was submitted from?
Yes, that's the standard way of doing it in Zeke - you define the schedule time and/or the conditions that must be satisfied and also the member name and library that is the source of the job. However, Zeke also allows for dynamically created schedule queue records (SQRs), whereby Zeke "captures" the JCL being submitted and manages it. Also, given the proper authorities, you can modify an SQR to read a different PDS member, run the job, then delete the SQR, leaving no clue behind. Admittedly, the last two scenarios are rare, and perhaps not noteworthy for this discussion. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Monday, June 06, 2016 5:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determine the PDS a job was submitted from? Did ZEKE actually submit the job or did it submit a "launcher" job that then submitted the one you are really interested in? I have never used ZEKE but surely it did not just up and decide to submit a job. Some form of input to ZEKE must have specified "when this condition occurs then " ZEKE should have some kind of report that allows you to see the active directives. The relevant directive must tell ZEKE where to find the job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Survey PDSE MAXGENS_LIMIT
We set ours to 4, but we haven't gotten around to experimenting with PDSE generations yet, so that was a SWAG for us, too. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, June 06, 2016 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Survey PDSE MAXGENS_LIMIT Not set yet, which defaults to zero. But thanks for the heads-up. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA) Sent: Friday, June 03, 2016 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Survery PDSE MAXGENS_LIMIT Curious what others are setting their MAXGENS_LIMIT at in the IGDSMS00 member in parmlib? We have ours set to 10 which was a swag. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL "COMMAND" statements
No, not me... My main contributions to the CBT are found in your stuff -- FILE452. But thanks for the thought. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dan D Sent: Tuesday, May 17, 2016 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL "COMMAND" statements I find the SDSF interface a little *clunky* and awkward. I prefer the CMD REXX from CBT (Greg Shirey maybe) ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Questions about EZAZSSI
I'm confused - you found a start command for EZAZSSI in COMMND00 or you didn't? Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Yuhas Sent: Monday, May 16, 2016 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Questions about EZAZSSI I am preparing for the first IPL of z/OS 2.2. I was reviewing the COMMND00 PARMLIB member and found a start command for EZAZSSI. I am totally unfamiliar with this address space. I googled it and found that EZAZSSI starts the TNF & VMCF address spaces. I reviewed the log from Saturday night's IPL and found this associated message - 'EZY6043I TNF Start Initiated'. I looked up the message: Explanation: A TNF address space start was issued. System Action: EZAZSSI continues; start of TNF expected. Of course, a similar message was issued for VMCF. I check our PARMLIB concatenation and did not find a start command for EZAZSSI; and, I know the IPL procedure did not start EZAZSSI? So, how did EZAZSSI get started? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another WLM question
I think you have it right, the RG cap should be enforced, based on the goal & importance for the service class and system scope -- From the Knowledge Base: If work in a resource group is consuming more resources than the specified maximum capacity, the system caps the associated work accordingly to slow down the rate of resource consumption. The system may use several mechanisms to slow down the rate of resource consumption, including swapping the address spaces, changing its dispatching priority, and capping the amount of service that can be consumed. Reporting information reflects that the service class may not be achieving its goals because of the resource group capping. By setting a minimum processing capacity, you create an overriding mechanism to circumvent the normal rules of importance. If the work in a resource group is not meeting its goals, then workload management will attempt to provide the defined minimum amount of CPU resource to that resource group. Minimum and maximum capacity has a system scope, that is, WLM ensures that the limits are met on each system within the sysplex. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tracy Adams Sent: Friday, May 13, 2016 12:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another WLM question So at what point with the service class get restricted based on the resource group settings? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QUESTION ABOUT CA-VIEWDIRECT
Willie, If you haven't gotten there yet, there should be a "JCL" library that was created on install with a member called DBLIST. You'll need to customize it for the data set names in use at your shop, jobclass, etc. and then add these lines to the end of it: //DBLIST.INCARD1 DD * ##TABLES 01 VERSION This will produce report RIN6002. Depending on how many archives you have, it can be a very large report... HTH, Greg Shirey Ben E. Keith Company -Original Message- From: willie bunter [mailto:williebun...@yahoo.com] Sent: Friday, April 15, 2016 11:27 AM Subject: Re: QUESTION ABOUT CA-VIEWDIRECT Thanks for correcting my mistake. I will see if I can dig up the report RIN6002. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How force dataset non-SMS?
OK, I ran this job: //EXEC PGM=IEFBR14 //SORTIN DD DISP=(NEW,CATLG),DSN=DPC088.TEST.BIG.DATASET,UNIT=SYSDA, // STORCLAS=XTRASC,SPACE=(CYL,(8000,40)),LRECL=80,RECFM=FB Which resulted in this SMS managed data set: NONVSAM --- DPC088.TEST.BIG.DATASET IN-CAT --- CATALOG.SYSTEMS.USERCAT HISTORY DATASET-OWNER-(NULL) CREATION2016.097 RELEASE2 EXPIRATION--.000 ACCOUNT-INFO---(NULL) SMSDATA STORAGECLASS -XTRASC MANAGEMENTCLASS---(NULL) DATACLASS ---DEFAULT LBACKUP ---.000. VOLUMES VOLSERXTRA31 DEVTYPE--X'3010200F' VOLSERXTRA3B DEVTYPE--X'3010200F' ASSOCIATIONS(NULL) ATTRIBUTES 100,545 tracks allocated across two volumes - utilization 0%. SMS may be getting in your way, but it would appear to be your local implementation. Looks like you'll need to talk to those guys Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, April 06, 2016 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How force dataset non-SMS? Still the same answer. I want a multi-volser dataset and SMS is getting in the way of that. Pure local test. No customers in the problem set. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How force dataset non-SMS?
You can only bypass SMS if the ACS routines allow you to bypass SMS. You might be able to add two candidate volumes after allocation: ALTER data.set.name ADDVOLUMES(* *) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 05, 2016 9:46 AM For a test of something relatively unrelated, I want to bypass SMS when allocating a dataset with DD. Is there an easy way to get SMS out of the way? Specifically, I am trying to force a dataset to three volumes. I have coded UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy bypass? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL V6 documentation available
I can't tell you there never was one, but if you are saying there was one in the 21st century, then I refer you to this post you wrote in June of 2005: " Tom, Suggest you create a SHARE requirement and submit it. Even then IBM COBOL won't do it. They have their heals dug so tightly in the mud on this one. OR even better somebody should write a MSG & Codes and sell it that would show IBM that it is needed. Ed" Here's the link: https://listserv.ua.edu/cgi-bin/wa?A2=ind0506=IBM-MAIN=0=-=1197298 I would think that if there had been a COBOL M manual produced in the last ten years, someone other than you on this fine list would be able to confirm it. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Tuesday, March 22, 2016 9:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL V6 documentation available Greg: When the first COBOL MVS and VM came out there was no M (this was mid 1990's) . Somewhere around 2005-7 there was a M I used to use it quite a bit in fact. AFAIR there was always a M for cobol (various versions and releases that go back to the 1960's) in fact I remember specifically in the mid-late 60's) using it to find out that the then current cobol did not support VBS. We had to back out a major change over to VBS on an online savings system. So do not tell me there never was one. I also remember the first ship COBOL program Product that did have a M as I had to make sure that it was distributed to all 200 programmers. I had to write a letter to IBM to ask permission to copy the fine manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL V6 documentation available
Ed, You posted this comment on June 15, 2012: "Somewhere around the mid 1990's IBM seem to have done a reverse and either stop issuing manuals (eg COBOL MESSAGES AND CODES) or made them so complicated to read (COBOL conversion guide) it takes a lawyer to understand them" Tom Ross posted this on June 17, 2012: "I know there is no reaching cranky Ed, but for others I can help: The issue of COBOL compiler messages was discussed here, and most agreed it would not be that helpful, since it would mostly say 'please see the COBOL Language Reference Manual'." I believe Tom was saying that there has never been a COBOL Messages and Codes manual. I'm not sure why you think otherwise. Can you locate one? My shop generally doesn't delete old manuals and we can't find one... In response to various comments about the lack of a manual over the years, Bill Klein reported back in 2005 that he had started an "annotated" list of COBOL error messages. It was incomplete, and I guess will remain so. It's probably not real important, but there doesn't seem to be any evidence to support your claim that IBM "finally" published a COBOL M manual. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Tuesday, March 22, 2016 9:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL V6 documentation available On Mar 22, 2016, at 1:47 AM, Bill Woodger wrote: > Ed, > > Are you seriously saying that for an applications language the > messages have to be able to be understood by someone with no knowledge > of the language, to someone who should know the language but doesn't > understand the message? Like I said the message that was put out had no relation to the issue. Too many FD's is a reasonable solution. The message didn't even message the were too many FD's. The programmers (in General) seemed to have a similar issue with many of the messages. Each time I got a phone call which should have been short turned into a 30 minute phone call which made me call IBM even asking other sysprogs before doing so. IBM wasted countless hours on each message I called in on. I hated it as did IBM trying to explain messages. IBM *FINALLY* put out a M after 5-7 years of requesting one so even they got the hint. The penny counters at IBM must be having a ball. Ed -- 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?
Found this in on old message on mvsforums: 0364 - JOBLIB/STEPLIB/JOBCAT/STEPCAT 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) Application Programmer Action: Use a different ddname, or consult your system programmer for the proper ddname to use. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield Sent: Saturday, March 12, 2016 4:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cannot allocate Steplib? I just started getting this error, though I cannot remember the last time I tried to (re)allocate steplib. IKJ56236I FILE STEPLIB INVALID, FILENAME RESTRICTED Something's funny because I'm sure I converted a clist to rexx 20+ years ago to loop through a listcat, pick out the steplibs, and put mine in front. And then when I went somewhere else and lost the scripts had to write another one, only to find out later someone else had also. Is it perhaps because my logon proc doesn't have a steplib in it? Or is there some parmlib setting that controls this? I looked through all the error docs and didn't find anything other than to use a different name. Thanks for your help. :) Lindy -- 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: VSAM file not extending to new volume
Thanks for reminding me. We have that PTF received but not applied. We'll correct that. I don't know exactly how the sysprog copied the DATACLAS definitions from 1.13 to 2.1 but, obviously, in the process that value got incorrectly set. What confused us and made us think we'd found a bug was the fact that we couldn't find any multi-volume VSAM files on our system. So, we thought something must be wrong. But we finally figured out that our production volume pool for VSAM files just has so much available space that there hadn't been any opportunities for data sets extending to another volume -- until yesterday. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Friday, February 26, 2016 1:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume This reminds me of an ISMF problem I has last year: did you do some updates to the dataclass definitions. Search the archives for: Heads up: ISMF error using the EOF key. It was solved by PTF UA77758, available in aug 2015. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: 25 February, 2016 18:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume Hmm, thanks for that. It looks like the EA value was NO instead of YES. I'll have to figure out how that happened. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file not extending to new volume
Hmm, thanks for that. It looks like the EA value was NO instead of YES. I'll have to figure out how that happened. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 25, 2016 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume Check for this in your data class DATA CLASS DISPLAY Page 2 of 5 CDS Name . . . . . : ACTIVE Data Class Name . . : DIRECT Data Set Name Type . . . . . : EXTENDED If Extended . . . . . . . . : REQUIRED Extended Addressability . . : YES Record Access Bias . . . . : USER Space Constraint Relief . . . : NO -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM file not extending to new volume
We upgraded to z/OS 2.1 on the 13th and all seemed well until this morning when several jobs were trying to write to a VSAM file and received this message: IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33, IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx The message indicates the file could not extend - but it should have extended to a new volume. The DATACLAS for our VSAM files has a Dynamic Volcount of 20. When we did a LISTCAT on the data set, it showed a second volume with VOLSER of * and VOLFLAG as CANDIDATE. (and Attribute of Extended) In order to recover the batch job, the applications group had to rebuild the VSAM file, so they did, then the sysprogs moved it to a volume with a lot of free space, and all the jobs ran fine. We generated a data set listing in ISMF and filtered on MULTIVOL = YES and our sequential data sets are successfully being extended to other volumes, but all of the VSAM files on the list only had CANDIDATE volumes after the primary. We've opened a PMR and searched the database, but we keep thinking we must have missed a migration step or something because we aren't seeing anyone else reporting anything like this. Any suggestions? Thanks, Greg Shirey Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM35912I_Error on Apply check
Call Compuware - they will be happy to guide you in fixing the issue.Unlike IBM, Compuware provides how-to assistance as part of their product support. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zos reader Sent: Thursday, February 04, 2016 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GIM35912I_Error on Apply check Hi All, I am applying cumulative maintenance for a compuware produce abendaid12.4. I have received the entire ptf's for 12.4 level, when i trying the Apply check it sounds some sysmods are missing. GIM30209E ** APPLY PROCESSING FAILED FOR SYSMOD ACD026Y. REQUIRED SYSMODS FAILED OR WERE MISSING. GIM35912ICONDITIONAL REQUISITE SYSMOD AAD026Y WAS MISSING. I also checked in SMPe panels to see whether the pre-requisite AAD026Y is there in TZONE or DLIB, but i can find AAD026Y is there in MOD for both TZONE & DLIB but its not allowing me to apply ACD026Y Can anyone guide me to fix this issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder (was: COBOL v5)
Hmm, the page displays a "Supper-scale Mainframe System" and a "Large-scale Mainframe System." If someone asked me if I'd rather have supper or large, I guess my answer would depend on how hungry I was.... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, January 28, 2016 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Binder (was: COBOL v5) http://www.fujitsu.com/global/products/computing/servers/mainframe/globalserver/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines
Interesting.It worked fine for me... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert AH Prins Sent: Monday, January 18, 2016 11:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines On 2016-01-18 15:34, Charles Mills wrote: > Depending on which of my several (G ...) IBM sign-ins I use, I > either get a password error or a 500. Deleting all IBM cookies (usually) helps, as does opening a "private" window on your browser. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why doesn't "="option work in SMP/E panels?
There may not be an "X" displayed on the menu, but it is a valid selection on the GIM@PRIM panel: VER(,LIST,0,1,2,3,4,5,6,7,D,T,W,X MSG=GIMIS007) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, January 13, 2016 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why doesn't "="option work in SMP/E panels? The IPCS main menu has an X option, so "=X" from anywhere in IPCS gets you all the way out. Surely SMP/E just needs an X option on its main menu. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZEKE and Console dialog
You asked this same question yesterday and received several replies. If they weren't satisfactory, perhaps you need to rephrase the question. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carl Edwards Sent: Wednesday, December 23, 2015 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ZEKE and Console dialog I have a client that is considering installing ZEKE. Said client has a fair amount of console dialog that needs to be automated. The questions is Can ZEKE recognize console messages generated via a program(DISPLAY UPON CONSOLE) and respond to such? -- 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 - originating jcl
It happens so rarely - normally the answer is "It depends." :-) Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Wednesday, December 16, 2015 3:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 - originating jcl It is astonishing how many words this group needs to reply: "No". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone using Rocket Software Performance Essential
Sorry, I don't think I'm understanding you. What product is it that you are saying is free and easiest to use? Thanks, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Mingee Sent: Tuesday, December 15, 2015 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Anyone using Rocket Software Performance Essential I used IAM, Rocket's Product and BMC Batch Optimizer. All of them provide great benefit in reduced run time by reducing I/O. My favorite isBat/Opt Standard Edition. Why, because it is FREE and easiest to use. Also, it provides stat reports that identify files that are read one recordper open(bad program code) even with proper buffering. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEFSSREQ SSOBUSER Validate A JES2 Destid
Could you be more specific? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of SUBSCRIBE IBM-MAIN Harold Gray Sent: Tuesday, December 01, 2015 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEFSSREQ SSOBUSER Validate A JES2 Destid Any more ideas on this issue? I have the same problem under z/OS 2.1 (not sure how far back it quit working - unable to bring up anything older than 1.13). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fastest way to read OLDEST GDG entry
Why does the process need to delete the oldest GDG after it reads it? Won't the oldest one be deleted when the next +1 GDG is created? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, November 17, 2015 4:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fastest way to read OLDEST GDG entry I have a request to read the oldest GDG to process. But CSI is slow sometimes and better other times. So here is the basic request File lands as a GDG often The process needs to read the oldest GDG and then delete it. GDGs must be read in correct order for time/date processing I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base. But using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work. Is there another process that could be used to identify the OLDEST GDG for Input and then delete that GDG? Or is there another way to handle this situation? I was going to see if the LISTC could be faster than CSI. The process should be native to z/OS and not a vendor product. Or shareware/freeware is okay. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM byte usage
Specifying RECORDS(X) may not be required if you have the XREPTEXT DD in the JCL. (At least in 1.13, and probably a bit earlier) At my shop, the housekeeping is done first, then another job creates the extended extract and the reports. Here's our step to write to the extended extract: //** //* Create a new DFSMSrmm Extract Data Set (Extended format) * //** //STEP01 EXEC PGM=EDGHSKP,PARM='RPTEXT,DATEFORM(A)' //SYSPRINT DD SYSOUT=* //MESSAGE DD DSN=SYS2.DFRMM.MESSAGE.FILE,DISP=SHR //XREPTEXT DD DSN=SYS2.DFRMM.REPORT.EXTRACT.FILE,DISP=SHR Hope this helps, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gonzalo Cengotita Sent: Monday, November 02, 2015 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMM byte usage How are you creating the extract file? You must use the DD XREPTEXT and the command: RPTEXT RECORDS(X,...) (X at least to get the extended extract records) *Gonzalo Cengotita* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM byte usage
See SYS1.SEDGEXE1, member EDGRRPTE: REPORT05 Inventory of Data Set Names include used kilobytes Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elaine Beal Sent: Thursday, October 29, 2015 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RMM byte usage We need a report of total bytes on tape. Is there an RMM report that will include the byte usage? Thanks, Elaine -- 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: 4-hour MSU rolling average
I use the following, which is similar to the REXX provided earlier in this thread (and liberally stolen from Mark Zelden). /* REXX */ CVT = C2D(STORAGE(10,4)) RMCT = C2D(STORAGE(D2X(CVT+604),4)) RCT = C2D(STORAGE(D2X(RMCT+228),4)) RCTLACS = C2D(STORAGE(D2X(RCT+196),4)) RCTIMGWU = C2D(STORAGE(D2X(RCT+28),4)) RCTCECWU = C2d(Storage(D2x(RCT+32),4)) IF RCTCECWU <> 0 THEN DO say 'The MSU capacity for this CEC is' rctcecwu'.' say 'The defined MSU capacity for this LPAR is' rctimgwu'.' END IF RCTLACS <> 0 THEN DO say 'The 4 hour msu average usage is' rctlacs'.' IF RCTLACS = RCTIMGWU & RCTIMGWU <> RCTCECWU THEN , say ' ** LPAR may currently be "soft capped". **' IF RCTLACS > RCTIMGWU & RCTIMGWU <> RCTCECWU THEN , say ' ** LPAR is currently "soft capped". **' END Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: Monday, October 26, 2015 2:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 4-hour MSU rolling average Thank you. That is the total capacity of the CEC, 28 on my machine. For SCRT purposes, I cap at 16. Is there a variable which I can look at to see how far under this cap I am, or when I am experiencing capping? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5
Timothy,
I take your point, and while I do admire your optimism, it was a year ago this
month that John Chase posed the question to this list whether anyone had
measured any performance improvements compiling programs with COBOL V5. There
was only one answer (from me as a matter of fact) and the results I reported
were mixed. I'd love to hear from others... (I'm optimistic too - but
cautiously)
Regards,
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Timothy Sipples
Sent: Wednesday, October 21, 2015 1:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5.x and CSP descendants was Re: New and improved IBM
migration recommendations for COBOL V5
Greg, thank you for acknowledging that IBM apparently neatly addressed your
concern with Option #1: IBM Program Number 5655-TRY. ("Operators are standing
by") However, I think you misunderstood or didn't appreciate the "So what!"
point I made. I'll spend a few more words elaborating on what I think is an
irrational "fear of the SVC."
"So what!" if your monthly charge for your COBOL compiler (only) increases
(*) when the highly likely outcome is
Your monthly z/OS charge decreases;
Your monthly CICS TS charge decreases; Your monthly DB2 charge
decreases; Your monthly MQ charge decreases; Your monthly IMS charge
decreases; Your monthly (whatever else) charge decreases; You defer the
charges associated with your next capacity upgrade; And you enjoy the new
compiler's new functions.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5
Timothy, With all due respect, it's real easy for you to say "So what!" That is not a justification for exceeding our software budget where I work. As for talking with my friendly IBM representative, well, I can't find one. My IBM VAR was helpful and gave it their best shot in working with IBM on extending the SVC (there was a lot of discussion at SHARE that IBM would be willing to do so) but ultimately reported that IBM would not. I had not read about CMP until now. That's interesting. If I'm reading it right, we are ineligible until we upgrade our z10. Your point about the developer trial is noted. Given our experience with this COBOL upgrade, we might look at this in the future. However, I submit that I was not incorrect nor was I complaining. Perhaps I was incomplete in my understanding of all the methods IBM uses for software billing, so I could have added more qualifications to my statement, but that still would not have turned it into a complaint. It is what it is, as they say. And, by the way, it's "Shirey". As the great Leslie Nielsen used to say "Don't call me Shirley." :-) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Tuesday, October 20, 2015 1:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5 Greg Shirley wrote: >Unfortunately, it gets a bit complicated when the changes that need to >be tested in the compiler come at a version level. Once you have >ordered a new version, you have a year to migrate off the old version, >or IBM begins charging you for running both. I'm afraid you're simply incorrect and repeating a complaint that has already been well discussed and debunked in this very forum. To revisit this topic in summary form, IBM provides at least two straightforward choices to avoid starting (or even having) the Single Version Charge (SVC) period: 1. Order the IBM Enterprise COBOL Developer Trial for z/OS. Use IBM program number 5655-TRY. You can conveniently order 5655-TRY on Shopz and get electronic delivery (in countries where Shopz is available) or order physical media (preferably DVD) elsewhere. Exactly as its name suggests it's a temporary evaluation license for non-production use of the full product. The trial license allows you to test and evaluate the value gained from Enterprise COBOL Version 5.2 before making a formal upgrade decision -- including CSP, VisualAge Generator, and/or EGL (preferably EGL) performance checks if you wish. 5655-TRY does *not* initiate a SVC period. 2. Upgrade/switch to IBM Country Multiplex Pricing (CMP), introduced earlier this year. CMP is available at least as close to worldwide as possible. There are no SVC periods under CMP at all. CMP does away with SVC periods for *all* IBM software products. There has also always been a third option: "Talk with your friendly IBM representative." No promises, but they tend to be reasonable people in my experience if you have a reasonable justification for an exception. Even if you somehow manage to get past all three of these perfectly reasonable, viable options, and if you then somehow exceed your one year SVC period, "So what!" Enterprise COBOL Version 5.2 yields performance benefits on practically every program you let it recompile and re-optimize. (How much? "It depends," but that's a fair generalization -- and see #1 above.) To the extent you can take advantage of Enterprise COBOL 5.2, even if it's not across 100% of your code portfolio, you (and your employer) are most likely a net winner in the efficiencies you pick up in your production environments. Even if you can recompile only a portion of your code portfolio that contributes to your peak utilization you still most likely win. Then there are the functional improvements, too. Once again I share John Gilmore's frustration. :-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5
Well, trust but verify, right? Unfortunately, it gets a bit complicated when the changes that need to be tested in the compiler come at a version level. Once you have ordered a new version, you have a year to migrate off the old version, or IBM begins charging you for running both. So, testing and gathering the evidence, if you will, of problems with compiled code becomes a bit of a gamble - will IBM get it corrected before the time runs out? We canceled our upgrade here for several reasons, one of which was that fixes kept being released for items that seemed beneficial but needed to be tested - we just ran out of time. We'll try again with 5.2 sometime next year. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: Timothy Sipples [mailto:sipp...@sg.ibm.com] Sent: Friday, October 16, 2015 3:03 AM Subject: Re: COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5 On this compiler a hypothetical NUMPROC(MIG) could well be worse! I trust the compiler designers' judgment on this performance question especially since they seem to have reviewed this issue. If you have performance benchmarking data that support your assertion that CSP, VisualAge Generator, and EGL customers must "put up with bad performance" after migrating to Enterprise COBOL 5.2, please show it. I'm sure the compiler team would be grateful to receive your data and will seriously evaluate it. There are no politics here, no hidden agenda, honestly. Minds are open. But so far as I am aware, IBM would assert the opposite. If you don't have such performance data, or if your performance data show something different than what you asserted, it would also be most welcome to hear that, too. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset enqueue, how to find the culprit.
According to Merriam-Webster online dictionary, one definition of "culprit" is "the source or cause of a problem." I suppose now there needs to be a discussion about whether the OP's situation could be defined as a problem... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Friday, September 18, 2015 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset enqueue, how to find the culprit. There is NO SUCH THINGS as a culprit! They are just doing their job and so are you. They just happened to collide. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS DELETE MASK and Recalls
Kees, We use CA-Disk to archive data sets. I issued the following in batch against migrated data sets: DELETE VTT.FSA.VT557.* MASK Result: IDC0896I MIGRATED ENTRY VTT.FSA.VT557.PAGEFILE DELETED IDC0896I MIGRATED ENTRY VTT.FSA.VT557.PARMFT DELETED IDC0896I MIGRATED ENTRY VTT.FSA.VT557.REPORT DELETED IDC0896I MIGRATED ENTRY VTT.FSA.VT557.TEXTT DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 CA-Disk r12.5; z/OS 1.13. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Thursday, August 20, 2015 1:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS DELETE MASK and Recalls Thanks Anthony, If another CA-DISK customer can confirm my problem, it looks like a CA problem. Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframes open to internet attacks?
I'm still trying to figure this out: More recently, when leaders of the U.S. office of personal management appeared before Congress to explain how sensitive data on millions of federal employees was accessed by hackers, they pointed to decades-old code written in a programming language called COBOL. Any ideas how COBOL facilitated a hack on sensitive data? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Meir Zohar Sent: Tuesday, August 18, 2015 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframes open to internet attacks? Phil Young has been doing these talks for several years and some of the tools are posted on his Soldier of Fortran site. He is absolutely correct in that some sites are complacent in their the mainframe is secure attitude and that, like every other platform, z/OS requires a continuous evaluate-correct-test-rollout-rinse-repeat security cycle ... Since security implementation on z/OS, independent of the tool, is the realm of either the sysprog (with little time to deal with it on a daily basis) or the security staff (where dedicated z/OS specialists are few and far between) - this can and does lead potential gaps in coverage. Ignoring the problem doesn't make it go away (however, Ashley Madison users' most sensitive information was never on z/OS). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
When I run your JCL, I get: IEFC620I UNIDENTIFIABLE CHARACTER ; ON THE DD STATEMENT Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roland Kinsman Sent: Friday, July 17, 2015 4:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 This JCL... //STEP01 EXEC PGM=IEFBR14 //ALC DD DSN=amp;XX00500, // DISP=(NEW,CATLG,DELETE), // DSNTYPE=LIBRARY, // UNIT=VIO, // DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), // SPACE=(CYL,(25,5,200)) works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails with the following error messages: IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING RETURN CODE 12 REASON CODE 144 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 It seems the key message is... HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 Which seems to suggest that PDSE cannot be allocated on VIO. So why does it work on one LPAR but not the other? It's making me a little crazy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS ROUTINE VARIABLES
USER is the User ID associated with the batch job. If you have a FILTLIST of the User IDs called, say, NOPDSES, then you can code: WHEN (USER EQ NOPDSES AND DSNTYPE EQ 'LIB') THEN DO WRITE 'NOT ALLOWED FOR PDSE' EXIT CODE(12) END HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, July 02, 2015 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS ROUTINE VARIABLES Hallo All, I am stuck with trying to figure out how I can code the variable for a Batch userid. For examle users aren't allowed to create a PDSe. I thought by coding the condition for the user's batch id it would solve the problem. However, I looked at all the SMS ACS read variable list but there is none for a batch id. Could anyone suggest how I can go about this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM Recalls and MASKING
If you issue the command TSO HELP HRECALL, example 3 is the example Tom provided. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andy Gilman Sent: Friday, May 29, 2015 9:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM Recalls and MASKING Tom, I looked for your example in the DFSMShsm Storage Administration manual and couldn't find it. Is it possible you are using some other tool to manage your HSM environment? Thanks. Andy -- 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: Slow storage creep in SYSTEM.SYSSTC
Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC service class. We put the systems programmers' TSO sessions there, for instance. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: Tuesday, May 26, 2015 6:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Slow storage creep in SYSTEM.SYSSTC We just had a zPCR study. There weren't any real surprises, but the Workload CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor really can control what falls into SYSSTC. It's all z/OS. I recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Sure. The sysprogs wanted to try and be sure they could get into the system in times of stress. We run a single LPAR on a machine with two processors, so CICS (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, May 27, 2015 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC Greg Shirey wrote: We put the systems programmers' TSO sessions there, for instance. TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm? Just curious, if you don't mind please. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS primary vsam space allocation
z/OS 1.5 introduced extent consolidation. The following is from z/OS DFSMS Using Data Sets SC23-6855-00: VSAM Extent Consolidation The system consolidates adjacent extents for VSAM data sets when extending on the same volume. VSAM extent consolidation is automatic and requires no action on your part. If the extents are adjacent, the new extent is incorporated into the previous extent. Example: The old extent begins on cylinder 6, track 0, and ends on cylinder 9, track 14, and the new extent begins on cylinder 10, track 0, and ends on cylinder 12, track 14. The two extents are combined into one extent beginning on cylinder 6, track 0, and ending on cylinder 12, track 14. Instead of two extents, there is only one extent. Because VSAM combines the two extents, it does not increment the extent count, which reduces the amount of extents. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Sent: Friday, May 22, 2015 4:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS primary vsam space allocation Reread your post, I don't know if listcat should do that, just that if space is available for a second extent right behind , vsam will put the together as one . On May 22, 2015, at 17:13, Doug dsh...@bellsouth.net wrote: SMS consolidated the primary with secondary because they were allocated back to back Doug . On May 22, 2015, at 17:10, Ward, Mike S mw...@ssfcu.org wrote: Hello all, I know this is late on Friday before a three day weekend, however, I'm stumped by a problem. We have some vsam files that have a primary allocation of 398 cyls and a secondary of 398 cyls. The primary extent that is displayed with in a listcat says that it is 11940 wihich is double the primary, secondary extents are 5970 tracks which is correct for 398 cyls. Can someone tell my why this is happening on an SMS managed file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Did I really need a CLIST???
Not even remotely? Okay, I'll bite. What point were you trying to make by your comment PUSH is one letter shorter. Thanks, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, May 21, 2015 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Did I really need a CLIST??? snip Coding subcommands in reverse order just to save one letter in each REXX command would be absurd. Are you having a fire sale on straw dummies? That's not even remotely related to anything that I wrote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14 question
Yeah, and shame on us for not discussing ways to achieve peace in the Middle East, too. What's the point of a technical forum anyway if we can't solve the big problems in the world?? Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony's Outlook via Mozilla Sent: Tuesday, May 05, 2015 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEFBR14 question All priors have been snipped away. ISTR another lengthy thread devoted to IEFBR14 cluttering the archives. While our old, trusty, favorite platform is being eaten alive by the toy computer tribe who are more adept at hosting EMAIL and web sites, a talent we can't or won't accomplish, we continue an electron stream to better understand this tiny load module. If we were the Edsel design teamif only we improve the ashtray -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14 question
The O/S may never use the data set after the step runs, but perhaps using the data set wasn't the point of running the step. I'd prefer the O/S not make that assumption for me. My 2 cents, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 05, 2015 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEFBR14 question On Tue, 5 May 2015 09:45:57 -0400, Steve Thompson wrote: How does the O/S know that this data set will never be used? Is it because of the PGM=IEFBR14? Yes. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14 question
Actually, it's the other way around. LEGACY is the default, you must explicitly specify NORECALL if that is the behavior you desire. (Unless that's changed in 2.1) You are right that it cannot be overridden in a particular job, but I would think to accomplish that would require more JCL - which if I remember correctly, you hate... Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 05, 2015 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEFBR14 question And yet, lately, the O/S makes such an assumption when the data set is migrated. Yes, as R.S. says, you can turn it off. It should be possible to override it within a particular job, not system-wide. OS/360 was not designed as a multi-user system. Its descendants inherit that original sin. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS QUESTION
Well, the question the OP posed was: Is it because it detected a problem with one dsn and doesn't process any of the dsns? If so, is there a work around it? I suspect the answer is yes to the first question, but this looks like a one-off process to me - something that only needs to be done once - so why the fuss? Just get it done... Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, May 05, 2015 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS QUESTION Your dataset is not managed by SMS - So you cannot alter the management class IDC3194I SMS CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS MANAGED Did you place your SYS2.CA1.TMSA on SMS managed volumes? Do you have the under control of SMS? - This is something I would not do for CA1 TMC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: migrating compiler versions
Great! Glad to hear that helped.We decided to go with the same option as well. As far as we can determine, we have no programs that read variable length record files but someone might create one in the future, and, if so, they should play by the rules. No sense encouraging poor programming techniques Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 03, 2015 6:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: migrating compiler versions Thank you! That example appears to have been removed from the COBOL 5.2 Migration Guide. :-( It does explain the behavior, for sure. It also helps me decide that I'm going to go with the new, correct, behavior with VLR(STANDARD). If we have any program that has this issue I am fine with getting an '04' instead of the '00'. This will probably cause the program to treat this as an error, which is fine because the program really should be corrected. We have few variable length files, and I am guessing no programs that exhibit this behavior. (Famous last words.) Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: migrating compiler versions
The COBOL 5.1.1 Migration Guide contains an example of how to test for it. Compile this program 4.2 and message “Incompatible wrong length read behavior” will display. (At least it did when I did it) * ** ** ** DESCRIPTION: This testcase tests if a compiler exhibits ** ** corrected COBOL V5 var length READ behavior. ** ** ** * IDENTIFICATION DIVISION. Program-id. READVAR. Environment division. Input-output section. File-control. Select File1 Assign to ddvar1 Access mode is sequential. Select File2 Assign to ddvar1 Access mode is sequential File status is fs2. I-O-control. Data division. File section. Fd file1 Record is varying Recording mode V. 01 Record1a pic x(20). 01 Record1b pic x(40). Fd file2 Record is varying 10 to 40 Recording mode V. 01 Record2a pic x(25). 01 Record2b PIC x(35). Working-storage section. 01 fs2 pic 99. 01 fs3 pic 99. 01 Errflag pic x value N. Procedure division. Display Starting READVAR. * * Create file1 with 1 20-byte record and 1 40-byte record * Open output file1 Move all a to record1a Write record1a Move all b to record1b Write record1b Close file1. * * Read file2 with 25 and 35 byte records defined * First READ should get FS=4 because 20 byte record is * shorter than the smallest record description * Second READ should get FS=4 because 40 byte record is * longer than the longest record description * Open input file2 Read file2 If fs2 = 4 then Display Corrected COBOL V5 behavior Else Display Incompatible wrong length read behavior End-If Read file2 If fs2 = 4 then Display Corrected COBOL V5 behavior Else Display Incompatible wrong length read behavior End-If Close file2. Goback. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 03, 2015 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: migrating compiler versions The RECORD CONTAINS clause is not required in either V4 or V5. It (if not present) is determined from the smallest and largest 01 level fields in the FD.Both V4 and V5 give a compiler error if there is a RECORD CONTAINS clause that does not match what would have been assumed had it not been present. I cannot figure out how to create a situation where COBOL V4 returns status '00' when there is a size mismatch. I always get '04'. Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Compiller options in IGYCDOPT
There's a discussion on the AWO option that may be of interest here: https://www.ibm.com/developerworks/community/forums/html/topic?id=4a12d0d1-9847-4e01-9586-e0897241edc0 Of note is this phrase from the manual: The APPLY-WRITE ONLY clause can cause input files to use a record area rather than process the data in the buffer. This use might affect the processing of both input files and output files. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of David Speake Sent: Monday, March 23, 2015 3:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Compiller options in IGYCDOPT Is there a historian in the house? Why is NOAWO the IBM default - since forever? I outlined for my SYSPROG the horrendous effect of LRECLs say of 80 and 32720 on device end channel traffic, run time and resource utilization. Question was raised about work loads that it might favor and why. There may be such workloads but I cannot imagine what they might be nor why. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS and TEMP DSN Parsing
I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SHARE Video
Really? All your co-workers are spending the day watching videos on You Tube and the only thing the boss complains about (to you directly) is what he perceives the cost of the video to be? That sounds odd. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Monday, March 09, 2015 10:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHARE Video Not to rain on anyone's parade, but I shared it with co-workers who promptly showed it to the boss and the boss came over to me and said if they have that kind of Money to throw away looks like SHARE is out of the budget next year and the foreseeable future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA/Reclaim Question
Run an IDCAMS EXAMINE on the data set and see if you get message IDC01718I Found empty control areas that have not been reclaimed. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs - Listserv Sent: Thursday, February 12, 2015 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA/Reclaim Question I'm not sure if I got my original question answered. We've enabled CA-Reclaim on the dataset, but I what I wanted to know does a repro back into the original dataset using the replace and reuse options, enable CA-Reclaim on all CA's, or do I need to reallocate the dataset? Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMLPARSE(COMPAT) for COBOL V5?
Yes. See APAR PI22094. Also, see APAR PI30156. HTH, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, February 04, 2015 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XMLPARSE(COMPAT) for COBOL V5? Has the promised update to COBOL V5 to support XMLPARS(COMPAT) been made available yet? According to presentations that Tom Ross authored last year it was promised sometime around third quarter 2014, but I have seen no official announcement yet. TIA for any help you can provide. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: TESTING SMS ACS ROUTINE OPTIONS VIA ISMF
Test for DSNTYPE=LIB. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Friday, January 23, 2015 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TESTING SMS ACS ROUTINE OPTIONS VIA ISMF G'Day, I have to test my changes to the SC routine before I put in production. I would like to test the routine to ensure that certain USER JOBNAME would allocate a PDS and PDS-E (LIBRARY). In the ISMF panel the option for DSORG I type PO and it works however I do not know what I should use for PDS-E or LIBRARY. The doc : DFSMS Using the Interactive Storage Management Facility, doesn't tell me how. Is there a way of testing for a PDS-E condition? Thanks. -- 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: DFHSM BCDS Z/OS 1.13
It is not mentioned in SYS1.HELP(ALTER) on my z/OS 1.13 system Is it in z/OS 2.1?? Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, December 12, 2014 9:33 AM Thanks for the update I was not aware of that. snip And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing Job Output class in ST screen in SDSF
Elardus, Entering the ? command displays the JOB DATA SET DISPLAY screen, as you note. Pressing F1 should display the HELP panel, option 3 will list the fields on the panel - there are 8 panels of fields to display. Panel 2 on my z/OS 1.13 system says this: Access for fields marked with * is immediate when JDS is accessed from H or O; otherwise, access for all fields is delayed. Title Description DDNAME Ddname of the data set StepNameOutput creation step name ProcStepOutput creation procedure step name DSIDData set ID Owner* User ID of SYSIN/SYSOUT owner C* Original or released output class Dest* Print destination name snip I don't know what delayed means in this context but it does seem to indicate that access to several fields (including output class) is different when the path to this screen is not via H or O. I cannot recall ever working on a system where I was able to overtype fields in the manner your colleague describes. IMO this is WAD. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, December 04, 2014 6:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Changing Job Output class in ST screen in SDSF Good day to all, Just curious, if you don't mind please. One of my colleagues wants to change a job output class (column S) in 'JOB DATA SET DISPLAY' in ST screen in SDSF. Ie, you enter a ? next to the job, press enter and see lines of different Job Datasets. Nothing on that screen is overtypeable. I am NOT talking about Column C in ST screen, but column C (OCLASS) in 'JOB DATA SET DISPLAY' (SDSF Secondary Panel) after you entered a line command '?'. Of course, I tried it out, RTFM, Googled, searched on IBM-MAIN + RACF-L, putting RACF profiles in SDSF class in warning, etc. Nothing - You can do the same thing in O or H screens. Turn access to None, you tab past that overtype-able field. Turn access to read, you can tab into it and modify your output class. I told the person to go to O or H screen and play there. He swears high and low he could do it on ST screen on another system. I tried the same on that system, but it is also configured the same as ours. Ok, I'm pretty sure there is nothing documented in SDSF book (z/OS v1.13). Did I missed something or is that WAD? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
It is still an option in COBOL 5.1.1. The default is NOSSRANGE. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, November 24, 2014 4:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SOC1 and SYSUDUMP and CEEDUMP There is - it is named SSRANGE for the Enterprise COBOL compilers, at least up through 4.2. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: curious: message rate to z/OS SYSLOG/OPERLOG on a _large_ system?
I'm surprised, but it looks like on an average day the SYSLOG generates 1.3 million lines. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 24, 2014 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: curious: message rate to z/OS SYSLOG/OPERLOG on a _large_ system? This is just a curiosity question. How many lines of SYSLOG output do you produce in an average day? I just did a quick look at last week's SYSLOG and saw about 1.5 million lines for a 7 day period on two, rather small, systems. Why am I curious? From a previous thread on doing a tail -f on the z/OS SYSLOG. I got curious about how much overhead this would be. I was warned by some very knowledgeable people that it could be a truly massive number of messages, and thus have high overhead. Which is making me rethink a possible project that I am considering. -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown -- 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 volumes from one storage group to other
Yes, of course you can move volumes from one storage group to another. The volume must be empty, however, as described on this page of the DFSMSdfp Storage Administration manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s2a1/13.7?SHELF=ALL13BE9DT=20120126150025 When you delete a DASD volume from a storage group, first set the volume status to DISNEW. This prevents any new allocations to the volume while allowing existing data sets to still be accessed with DISP=SHR, DISP=MOD, or DISP=OLD. Move any data that you do not want converted to non-SMS from the volume. Next, if the DASD volume is to be reused as a non-SMS-managed volume, run a DFSMSdss NONSMS CONVERTV to convert it out of SMS. Finally, remove the volume from the storage group. To remove DASD volumes from a storage group, select the Storage Group Application Selection panel. Specify the CDS name and the storage group name that contains the volumes you want to delete. Press Enter to get the Storage Group Volume Selection panel. From the Storage Group Volume Selection panel, indicate the volumes you want to delete in the SPECIFY A SINGLE VOLUME (in PREFIX), OR RANGE OF VOLUMES field, select option 4, and press Enter. Be careful when moving or removing a volume from a storage group because the volume could contain part of a multivolume data set. The changes take effect when you activate this updated configuration. To prevent DFSMShsm from attempting to allocate to volumes which have been deleted from the storage group, issue the DFSMShsm DELVOL command from all DFSMShsm systems which are aware of the deleted volume. After deletion, the DASD volume is only eligible for non-SMS allocations. However, if you are reassigning the volume to another storage group, you need to define the volume to the storage group and then activate the updated configuration. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Meenakshi, Vinoth - CW Sent: Monday, November 10, 2014 2:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Adding volumes from one storage group to other Hi All, I have only little knowledge on Storage side and I need to perform below activity. One of the storage group TESTA is getting filled up and its almost utilized and only 6% free space is available. I am trying to add some MOD9 cylinders to TESTA storage group. Also i have free volumes in TESTB group which is not utilized and it has enough free space. Can we add few volumes from TESTB storage group to the TESTA storage group using ISMF or is there any other way to add volumes to a specific storage group. Kindly assist me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
We have applied the COBOL fixes for September, and now the optimizer discarded messages are appearing in the compiler output. The format and message identifier has changed. COBOL 4.2: IGYOP3091-W Code from procedure name 300-PROCESS to EXIT (line 155.01) can never be executed and was therefore discarded. COBOL 5.1: IGYCB7300-W The code from lines 105.1 - 106.1, 109.1, 110.1 - 111.1, 112.1, 115.1, 116.1 - 117.1, 117.1, 119.1 - 122.1, 122.1, 125.1 - 126.1 in program 'MAKEEX' can never be executed and was therefore discarded. IGYCB7300-W The code from lines 126.1, 127.1 - 129.1, 129.1 - 130.1, 135.1, 136.1, 139.1 - 141.1, 141.1, 146.1 - 147.1, 147.1, 148.1 in program 'MAKEEX' can never be executed and was therefore discarded. IGYCB7300-W The code from lines 149.1, 152.1 - 154.1, 154.1, 155.1 in program 'MAKEEX' can never be executed and was therefore discarded. As the code snippet below shows, COBOL 4.2 would throw out everything after STOP RUN. COBOL 5.1 only discards the statements on the SL lines. (I've forgotten what SL means in COBOL.. I am no programmer...) LineID PL SL +-*A-1-B--+2+3+4+5 000100STOP RUN. 000101 000102300-PROCESS. 000103 000104IF END-OF-FILE 000105 1MOVE YES TO END-OF-BUILD 000106 1GO TO 300-EXIT 000107END-IF. IBM support was not helpful in letting us know which of the PTFs from September fixed the issue. HTH, Greg Shirey Ben E. Keith Company On Friday, October 3, 2014, Tom Ross said: COBOL V5 optimization definitely removes unreachable code, but it is so different from the V4 optimizer that it may report differently. In fact, in the early days (of developing COBOL V5) we were getting messages for deleted code at OPT(0), which we have since corrected (we no longer delete code at OPT(0)) The COBOL V3/V4 optimizer did not always report unreachable code deletion, but we are interested in cases where V4 flagged it and V5 does not, so please open PMRs if you find such cases! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
The original question in this thread was: Has anyone implemented COBOL 5.1 to the point that you have measured the promised performance improvements in application code over the same code compiled with earlier COBOL compilers? We have compiled a few of our programs that run as part of some utility jobs that run daily and modified the JCL to run both the COBOL 5.1 version and the COBOL 4.2 version. Mostly what these jobs do is read some input file, select certain records or fields and create a new data set with what was selected. So, none of them have a real large Procedure Division. The output below is from a Food Lion SMF report (file 19 on the CBT) - it's formatted in my email, I hope that doesn't get lost. The first entry for each program on the listing the COBOL 5.1 run - in the case of COBSAM81 program, the first one was compiled OPT(2) and the second OPT(1) (and we run on a z10/BC, so we compiled ARCH(8)). Mostly, the 5.1 programs show improvement in CPU time and in below the line region. The elapsed time does not always improve, and sometimes gets worse, but not significantly worse. COBOL COMPARE JOBS RUN PROGRAM CPU TIME ELAPSEDTOTAL SERVICE REGION REGION NAME :SS.TH TIME I/O UNITSBELOW ABOVE COBSAM610:00.33 000:00:03 10,7597K .3M 14.4M COBSAM610:00.33 000:00:04 10,7207K .6M 13.5M COBSAM810:23.46 000:03:09 1,093,331 591K .3M 17.5M COBSAM810:23.12 000:02:39 1,093,329 586K .3M 17.5M COBSAM810:23.52 000:03:04 1,093,277 577K .6M 16.5M MAKEEX 0:03.95 000:00:57104,410 83K .3M 14.4M MAKEEX 0:08.11 000:01:01104,342 162K .4M 13.6M SS090 0:02.97 000:01:02 97,874 64K .3M 14.1M SS090 0:03.03 000:00:43 97,790 64K .3M 13.4M SS092 0:12.87 000:01:34110,679 265K .4M 14.9M SS092 0:12.67 000:01:01110,584 246K .3M 13.7M SS604 0:04.18 000:00:50104,250 88K .3M 14.1M SS604 0:05.00 000:00:46105,714 101K .3M 13.3M So, this is not application code, but it is what we have measured so far. HTH, Greg Shirey Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
Well, at no time have *I* suggested that the new compiler should be avoided, only that a bug should be fixed (if there is one). If this changed behavior with the optimization of a COBOL program is not a bug, then I will be enlightened by IBM's explanation and this discussion, and be in a better position to explain to the programmers in my shop how this new version of COBOL will operate. I'm not sure where you're seeing impatience and offense towards IBM, but I will agree with you that this new compiler is superior to the predecessors. I'm eager to start having the programmers use it. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, October 03, 2014 5:05 AM snip So far, we do not appear to be dealing with defective optimizations that make a routine unusable. Instead we are dealing with situations in which further optimizations are possible. That being the case, some patience is in order. This new compiler is, on balance, much superior to its predecessors; and crotchets of this sort do not constitute a legitimate arguments for avoiding its use. Until now I avoided contributing to this thread on the assumption that IBM was well able to defend itself and did not need my herlp in doing so. This post reflects my, changed, view that some other posters have misunderstood this 'deficiency' and the nature of optimization in general. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
Charles, COBOL 5.1 has three settings for optimization OPT(0), OPT(1) and OPT(2). We're testing COBOL 5.1 at OPT(2), so, yes, we tested at the full optimization. Inside the paragraph that never gets executed, I added the following statement: MOVE BUBBA to WS-DESC. After recompiling with OPT(2), I browsed the program object and was able to find BUBBA which leads me to believe that the optimizer is no longer removing code that cannot be executed. (At least in this case.) Is that a bug? I'll ask IBM and report back. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, October 01, 2014 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL v5.1 Implemented? That's weird, because that is one of the things that an *optimizing* compiler tends to notice: hey, I tried to optimize this, and when I did I optimized it right out of existence! Have you tested with full optimization on? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
Hmm, remove the code but not the literal? That seems more trouble than it's worth and to what end? I could probably look at the pseudo assembler listing, but that's not my strong suit. What does it hurt? Well, if I wrote a COBOL program and the compiler reported that a huge chunk of it was discarded because it would never be executed, my response would probably be Oops, I didn't mean to do that.With COBOL 5.1, I won't know part of my program is not executing until I possibly don't get the results I expected. Right? Regards, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, October 02, 2014 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL v5.1 Implemented? Well, I suppose it is possible that it is removing the *code* but not the literal. Does COBOL 5.1 have a show me the pseudo-assembler listing option? That would provide a better test IMHO. Of course, the real harm in not removing unreachable code is pretty modest IMHO. Makes your executable larger, which uses DASD, and virtual storage, and fetch time, and slightly reduces i-cache hit probability, and perhaps gets in the way of short relative jumps -- but all pretty modest effects IMHO. Or am I missing something? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
Okay, I had been working with a small program with a couple of lines of removed code. So, I took a program where the PROCEDURE DIVISION had some 3900 lines of code, and was basically coded like this: Open File 1 Open File 2 Move some values around SORT with INPUT PROCEDURE and OUTPUT PROCEDURE Close Files GOBACK. I commented out the SORT statements and compiled COBOL 4.2 with full optimization and got this message: 7996 IGYOP3091-W Code from procedure name 2000-READ-VENDOR to GO (line 13628.01) can never be executed and was therefore discarded. So, some large number of lines of code (from line 7996 to line 13628) was discarded. Compiled source code COBOL 4.2 with OPT(FULL): MODULE SIZE: D0A8 Compiled source code COBOL 4.2 with NOOPT: MODULE SIZE: 0001EC18 Compiled source code COBOL 5.1 with OPT(0): MODULE SIZE: 0003D72C Compiled source code COBOL 5.1 with OPT(2): MODULE SIZE: 0002CB3C So, it does appear that there is some optimizing of the code happening with COBOL 5.1, but if lines are being discarded, the compiler is not reporting on it. Thanks for the feedback, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, October 02, 2014 10:53 AM Greg Shirey wrote: Inside the paragraph that never gets executed, I added the following statement: MOVE BUBBA to WS-DESC. What are the conditions you set that the part will never be executed? In a part of boolean statement which are always FALSE or is that a part of a routine/function which are never called at all? After recompiling with OPT(2), I browsed the program object and was able to find BUBBA which leads me to believe that the optimizer is no longer removing code that cannot be executed. (At least in this case.) Weird. Are the module size the same with all these OPT values? It should be different. Is that a bug? I'll ask IBM and report back. Perhaps, but exclude any debugging compile/linkedit options and search again for 'JABBA', oops, 'BUBBA'. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: object/load module sizes - was RE: Enterprise COBOL v5.1 Implemented?
No problem, but please allow me to snip from the bottom... I'm using the same compile and link parms (where they are the same), and I am compiling NOTEST. IIRC, Tom Ross gave several reasons for the increase in program object size from 4 to 5. The only one I can find from his SHARE presentation is on page 82: Binder solved existing problems using new features. A program object can have a text size of up to 1 gigabyte. COBOL can take advantage of this by having more constants for improved MOVE and INITIALIZE performance. Makes object size bigger (From zOMG The Next COBOL Compiler has Arrived!) Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, October 02, 2014 1:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: object/load module sizes - was RE: Enterprise COBOL v5.1 Implemented? In an attempt to not hijack the thread I'm changing the subject line. Do you have some significant differences in your compile or link parms between COBOL 4 and COBOL 5? What would be accounting for the rather significant load module size growth between 4 and 5? Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: object/load module sizes - was RE: Enterprise COBOL v5.1 Implemented?
To be clear, though, about the examples I posted - they were all program objects (whether compiled COBOL 4 or 5) and stored in the same PDSE. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, October 02, 2014 2:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: object/load module sizes - was RE: Enterprise COBOL v5.1 Implemented? Oversimplifying only a little, program objects are almost always a bit bigger than the corresponding load modules, and they can bedramaticallyb so when significant blocks of storage are initialized with constants. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 Implemented?
John, We're almost to the point to begin trying to measure performance improvement, so if I find anything significant I'll post it later, but have you seen the SHARE presentation from Tom Ross where he documents how performance improvements are achieved? It's informative, and can help guide you in what to look for. As far as other glitches, I posted a message yesterday about the absence of IGYOP messages, and specifically IGYOP3091-W. In further experimenting, we have discovered that it's not just that the message isn't being produced, it's that the code that can never be executed is not being discarded as it was in COBOL 4.2. So, there's no message about it because the compiler is no longer doing what it used to do. We intend to open a PMR in the morning and see what response that yields. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chase, John Sent: Wednesday, October 01, 2014 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Enterprise COBOL v5.1 Implemented? Hi, All, Has anyone implemented COBOL 5.1 to the point that you have measured the promised performance improvements in application code over the same code compiled with earlier COBOL compilers? Any hiccups or other glitches or gotchas you'd care to mention with COBOL v5.1? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL 5.1 optimizer messages
Hello all, I was comparing output from the COBOL 5.1 compiler to the output from the COBOL 4.2 compiler, and noticed that for the program I chose to compile the 4.2 output contained message IGYOP3091-W Code from xxx to xxx can never be executed and was therefore discarded but the 5.1 output did not. I found a posting on the COBOL Café website asking about the absence of all IGYOP messages from COBOL 5.1 compiles - this person seems to have done many more experiments than I, which saves me that trouble. There was a response from a Reid Copeland asking for a snippet of code so we can investigate which was provided by the OP, but that's where the exchange seems to end. This was back in June. I ran the ERRMSG program and the message I was expecting was on page 47. PP 5655-W32 IBM Enterprise COBOL for z/OS 5.1.1 ERRMSGDate 09/30/2014 Page 47 IGYXX3091-W Code from ? to ? can never be executed and was therefore discarded. So, I think it's PMR time, but I wanted to run it by anyone who has been experimenting with COBOL 5.1 - have you seen any of the optimizer messages? Has anyone already opened a PMR for this issue? (I searched but didn't find one) Thanks, Greg Shirey Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I don't know if this helps, but APAR OW36048 contains the following information: If you found incorrect data set names for any DDDEFs in your primary target zone and have already installed maintenance on the new system, IBM recommends that you run the SMP/E REPORT CALLLIBS command against this zone now. Then run the CALLLINK job generated by SMP/E. This will ensure that load modules containing external references are link-edited correctly on your system. This APAR was closed in 1998, but may still be applicable. By the way, it specifically notes that if your serverpac order did not have C/370 that the DDDEF for SEDCBASE would be directed to CEE.SCEELKED. I've never run CALLLIBS or CALLLINK, so I don’t know what they do, so proceed with caution. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E THanks .But my initial serverpac came without C/370 product and we installed like below REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RES001) UNIT(3390) WAITFORDSN SHR . But later when I received CBPDO from from IBM for C/370, it allocated SEDBASE dataset but as DDDEF was pointing to SCEELKED, so data related to this FMID went to SCEELKED and SEDBASE is empty for me . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Meet Cobol's hard core fans
But I'm not surprised to see that Gartner is still predicting mass migrations off the mainframe in 3 to 5 years: For these mainframe-centric businesses, the Cobol application suite that runs the heart of the business isn't going anywhere. But they still need to deal with the declining Cobol workforce . . . to keep these systems viable for the next decade or two, says Dale Vecchio, research vice president at Gartner Inc. As for the other 90% of businesses running mainframes today, Vecchio thinks the Cobol brain drain will be the catalyst for more extensive migrations off the platform, through rewrites, moves to packaged applications or recompiling and re-hosting Cobol on distributed computing platforms. After years of foot dragging, the looming Cobol brain drain will force many organizations into making a decision -- one way or the other -- within the next three to five years. Increasingly, I see this transition happening, Vecchio says. Waiting isn't going to make this any cheaper, and it isn't going to reduce the risk. They've been predicting that for close to 20 years now, I think. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, August 21, 2014 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Meet Cobol's hard core fans I'm somewhat surprised to see an IBM employee publicly disclosing such business statistics. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO EDIT COMMAND - BOUNDS
Possibly because there is no BOUNDS operand to the TSO EDIT command? Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, July 25, 2014 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO EDIT COMMAND - BOUNDS The Subject: refers to the TSO EDIT command. All the replies I see seem to pertain to the ISPF Edit command. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS QUESTION - RECATALOG
If you enter TSO HELP DEFNVSAM on your command line, you might see:
FUNCTION -
THE DEFINE COMMAND CAN BE USED TO CATALOG A NONVSAM DATA SET IN A
VSAM CATALOG.
SYNTAX -
DEFINENONVSAM
( NAME('ENTRYNAME')
VOLUMES('VOLSER' ...)
DEVICETYPES('DEVTYPE' ...)
COLLECTION
FILESEQUENCENUMBERS('NUMBER' ...)
OWNER('OWNERID')
TO('DATE') | FOR('DAYS')
RECATALOG | NORECATALOG )
CATALOG('CATNAME/PASSWORD')
REQUIRED - NONVSAM, NAME, DEVICETYPES, VOLUMES
DEFAULTS - NONE
HTH,
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of willie bunter
Sent: Wednesday, July 02, 2014 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IDCAMS QUESTION - RECATALOG
Good Day,
Can you spot my error. I am trying to define the VVDS to a specif USERCAT. Is
the RECATALOG option allowed?
DEF NVSAM -
(NAME(SYS1.VVDS.VPROM56) -
DEVT(3390)-
VOL(PROM56)) -
CATALOG(SYS1.ICFCAT.SYSPRM) -
RECATALOG
IDC3211I KEYWORD 'RECATALOG' IS IMPROPER
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS 12
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12
--
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: HP P4015tn paper tray selection
I'm confused by your references to the manual paper feed and tray 2. You said there are three paper sources, so if tray 3 and tray 4 are two of them, the third one is either the manual feed or tray 2 - or are they one and the same? Regards, Greg Shirey Ben E. Keith Company From: Rick Stetser Sent: Wednesday, June 18, 2014 9:45 AM To: IBM Mainframe Discussion List I have a developer who's trying to print on an HP Laserjet P4015tn printer that has three paper sources. The first one, I think, is the manual paper feed and the other two are actual trays that hold paper and they’re marked 3 and 4 on the outside of the tray. The developer is trying to get the forms from the bottom tray (marked 4) to print but without success. The document data is AFP which is transformed to PCL via IP Printway (hereafter called Infoprint). We're using a FORMDEF that looks like this: SETUNITS 1 IN 1 IN; FORMDEF WHDOC OFFSET .158 .197 JOG YES REPLACE YES; COPYGROUP LODRWRPT BIN 2 OFFSET .158 .197; COPYGROUP UPDRWRSS BIN 3 OFFSET .158 .197; COPYGROUP DRWTHREE BIN4 OFFSET .158 .197; Currently we print this document (using a slightly different FORMDEF) so that one page comes out on plain paper from tray 3 and the other paper has special paper stock and prints from tray 2. The change that’s being tested is to have an additional page print on plain stock from tray 4. What’s actually happening is the additional page is printing from tray 2. If the FORMDEF COPYGROUP DRWTHREE, is changed to BIN 2, the stock draws from tray 3. We tried playing around with the AOP_TRAYID settings changing the fourth position to all of the values from 1 to 5. In many cases that caused the printer to draw from the manual paper feed. If anyone has any suggestions on this I would sure appreciate it. We're z/OS 1.13. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
