Re: BMC CMF
We run CMF since ages, so I don't know RMF, but we are very happy with it. Compatibility is 101%, the standard 70-records are the same as RMF's and they write extra info in CMF records. BMC has a close relation with IBM, so they follow new z/Oss and hardware promptly. I can recommend the MAINVIEW products, there are several. They provide an excellent detailed view into your system. Kees. Paul Peplinski paul.peplin...@wpsic.com wrote in message news:8144080530169812.wa.paul.peplinskiwpsic@listserv.ua.edu... We are looking at using CMF instead of RMF and would be interested in current user experience as far as compatibility (MXG, SCRT, reporting), reliability, and CPU consumption (including zIIP). Also if there are any benefits gained in Mainview by doing so. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App
Am 01.06.2012 18:43, schrieb Lizette Koehler:
Cross Posting to IBM Main and TSO-REXX
I have a Rexx process that issues the HLIST command. I have been successful
in trapping the output from the HLIST but have an issue when the message
ARC0138I is issued.
I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
etc)
I have tried turning off message for that section of the code MSG('OFF')
Any yet it keeps getting produced so the user has to keep hitting enter
until they are cleared.
This message can be overwhelming if my user requests 100's of datasets that
do not have an MCDS entry.
Does anyone know if this message can be suppressed from a TSO session? IF
so, suggestions?
Thanks
Lizette Koehler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
HI
Use X = MSG(OFF) before the TSO Comand and X = MSG(ON) after
Giovanni
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App
On 6/3/12, Giovanni Santuz gsan...@gmx.de wrote:
Am 01.06.2012 18:43, schrieb Lizette Koehler:
Cross Posting to IBM Main and TSO-REXX
I have a Rexx process that issues the HLIST command. I have been
successful
in trapping the output from the HLIST but have an issue when the message
ARC0138I is issued.
I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
etc)
I have tried turning off message for that section of the code MSG('OFF')
Any yet it keeps getting produced so the user has to keep hitting enter
until they are cleared.
This message can be overwhelming if my user requests 100's of datasets
that
do not have an MCDS entry.
Does anyone know if this message can be suppressed from a TSO session?
IF
so, suggestions?
Thanks
Lizette Koehler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
HI
Use X = MSG(OFF) before the TSO Comand and X = MSG(ON) after
Giovanni
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App (SAMPLE)
Am 03.06.2012 04:10, schrieb Shmuel Metz (Seymour J.):
In
CAOdPEgRBghL+Cqd4qZryi2rYXVaUFY=9e-ugencg8mphj93...@mail.gmail.com,
on 06/02/2012
at 12:02 PM, Itschak Mugzachimugz...@gmail.com said:
Did you try REXX OUTTRAP function?
OUTTRAP catches PUTLINE and PUTGET, not TPUT.
HI
Here a sample to Do a HLIST, and process the info in the REXX.Proc
Data is written in the STEM HSMI.
ODSN = Name of the DSN
RD ist a Random number to be able to alloc a Unique file
This is part of a proc that processes 100.000 Files thru a Batch file
Hope it helps
Giovanni
RD =RANDOM(1,9)
HSMDS = 'TWRK.TEMP.D'!!RD
HLIST DSNAME('ODSN') ODS('HSMDS')
CALL READ_HSMDS
READ_HSMDS:
ALLOC DATASET('HSMDS') File(HSMDS) SHR
EXECIO 0 DISKR HSMDS (OPEN
EXECIO * DISKR HSMDS (STEM HSMI.
EXECIO 0 DISKR HSMDS (FINIS
X = MSG(OFF)
DELETE 'HSMDS'
X = MSG(ON)
FREE DD(HSMDS)
RETURN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STK SMC/HSC and SMS Tape
If SMS TCDB (aka VOLCAT) has a volume entry SMS111, the DD1 allocation with DISP=OLD goes to the SMS Tape Library even though SMC/HSC control data set has a volume entry SMS111 for the volume in the SILO. As you know, DISP=NEW allocation is controlled by SMS ACS routines you wrote. If you want to allocate the volume SMS111 on the SILO, you have to add STORCLAS=DUPT@SMS parameter in the DD1 DD JCL. (If SMS TCDB has the volume entry SMS111) Minoru Massaki (M*M) 2012/6/3 Tom Williamson t...@dtssoftware.com: Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- 全先 実 - Minoru Massaki (M*M) E-mail: mmass...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App (SAMPLE)
On Sun, 3 Jun 2012 17:06:35 +0200, Giovanni Santuz wrote:
RD =RANDOM(1,9)
HSMDS = 'TWRK.TEMP.D'!!RD
HLIST DSNAME('ODSN') ODS('HSMDS')
CALL READ_HSMDS
Is RANDOM() the best way to do this, given that there's a 50%
chance of collision in 372 tries? Would it be better (and more
informative) to generate a DSN using date/timestamps (despite
a certainty of collision if the script is run twice in one second)?
The real shame here is that DFSMShsm does not support using
a temporary DSN (or z/OS UNIX (USS) file or pipeline) by providing
either an OUTDDNAME or an OUTVOL parameter.
READ_HSMDS:
ALLOC DATASET('HSMDS') File(HSMDS) SHR
EXECIO 0 DISKR HSMDS (OPEN
EXECIO * DISKR HSMDS (STEM HSMI.
EXECIO 0 DISKR HSMDS (FINIS
Can't the above 3 commands be collapsed into one (OPEN
is utterly superfluous -- assembler habit?):
EXECIO * DISKR HSMDS (FINIS STEM HSMI.
X = MSG(OFF)
DELETE 'HSMDS'
X = MSG(ON)
FREE DD(HSMDS)
RETURN
I read in:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2U390/2.6
Title: z/OS V1R12.0 DFSMShsm Managing Your Own Data
Document Number: SC35-0420-09
2.6 HLIST: Listing information from the BCDS and MCDS
...
The HLIST command is a long-running command that can tie up your TSO
terminal if its output is directed to TERM.
Should I infer from this that conversely it runs concurrently
in background and does not tie up the terminal if output is
directed to SYSOUT or ODS? If so the above EXEC needs a
WAIT to guarantee that the output is complete. (Or does
ENQ SHR handle this?)
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STK SMC/HSC and SMS Tape
On Sun, 3 Jun 2012 03:21:33 +, Tom Williamson t...@dtssoftware.com wrote: Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom I've run both together, but never with duplicate volsers. HSC/SMC was using TAPEREQ to control allocations, not SMS.SMC eliminates devices from the EDL when it know the tape is one of its own, but I'm not sure if that is before or after SMS gets involved. Either way, STORCLAS=DUPT@SMS should let you get at the STK tape in the ACS. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Brain drain: Where Cobol systems go from here
Kirk, Yes, I agree also and the ability to read a manualhave a ton of customers who don't even take the time to rtfm..l Scott ford www.identityforge.com On Jun 1, 2012, at 5:33 PM, Kirk Talman rkueb...@tsys.com wrote: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/23/2012 05:39:26 PM: From: Roberts, John J jrobe...@dhs.state.ia.us When the last Cobol programmers walk out the door, so may 50 years of business processes within the software they created. Will you be ready? Ed, Interesting article and fairly accurate IMO. This is what I can foresee happening: (1) Many companies will try to offshore their COBOL application support. But this won't work so well because it is hard enough to understand these systems without facing the complications of language and arcane terminology. And the young ones back in Bangalore will want to do Java, not COBOL. Actually the language is not a problem. We have people here from multiple nations, some whose English is lacking. But they can doing the programming work - well. The problem is the lack of application knowledge. We just had a senior person retire to a ranch in FL. He was senior person in his critical application. He ran a series of weekly one hour technical seminars. The problem was that he could answer any question off the top of his head. But an organized overview and drill down into each part of the system and the relationship of that system to multiple other systems was not there. He was used to being a S(ubject)M(atter)E(xpert)/guru. Ask him a question and he could answer it or tell you where to find the answer. Without that kind of person, trying to port the application to anything else is risky as is training newbies. (2) Other companies will want to recruit overseas, either for CS grads that they can train, or for those few that are willing to invest in COBOL learning if that is what it takes to punch that H1B ticket. But even so, once here they are all going to be looking to do something else, not COBOL. So that company that recruits and trains a COBOL resource is going to be looking for a replacement within a couple years. We have had over the years training programs to build new Cobol programmers. They work fine. But again, the application knowledge is not in books. It was transmitted by SMEs. (3) Efforts to train new young COBOL resources are going to flop, as the article mentions. Again, everyone expects COBOL to be a career dead-end once beyond a 5 to 10 year transition period. Since Cobol is now talking to distributed applications in various ways, Cobol people are getting exposure to distributed applications. I recently had a project transferred from me which was going to have me build part of an environment that is both mainframe and distributed. As long as the documentation is there, there is not a huge chasm to cross. (4) In the end, US companies are going to be forced to pay a premium just to hang on to their old-timers long enough to buy time to implement that new ERP package or new custom application. The ones that will be successful doing this are going to be the ones that accommodate their senior developer's desires: lots of time off, telecommuting, job sharing, benefits, etc. Right now at the moment there are enough Cobol programmers leaving other companies that is still a supply of new people, some of which have fine skill sets. But as time goes on, there will be a cliff. I just returned from Germany. There was talk there that there is an engineering shortage in the market there. Never bothered with the details. Maybe the recession there will give them time to kick the can down the road more. After all, it has been working so well for dealing with their financial problems. John - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff
