Re: Why doesn't "="option work in SMP/E panels?
That is the only technically correct answer. For that reason I have macro button in my terminal emulator that does: =x;=x;=x;=x;=x;=x;=x;=x; to get back home from wherever you are. Further, we have a lot of handy commands to go directly to useful functions. From any panel I can enter: DSL to invoke the DSLIST panel directly. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alan Haff Sent: 13 January, 2016 19:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why doesn't "="option work in SMP/E panels? The SMP/E Primary Option Menu is coded with "&ZPRIM = YES". The ISPF "RETURN" command (and its companion, "=") returns control to the immediately-preceding primary options menu. Let's say you're in Sysmod Management panel, for example. If you enter "=3", you'll move to the SMP/E Query Selection Menu, not the ISPF Utility Selection panel. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and FONTS; Moving from z/OS 1.13
Gibney, David Allen,Jr wrote: > I have a small shop, 4 monoplex LPARs, no GRS. Very careful sharing of a > limited set of disks including the system resident (IPL) volume, a Mod-27. Up > until now, I have made separate (R/O) copies of the ROOT and other system > ZFS/HFS(s) for each LPARs. > This new Unix filesystem with FONTS is not small and I am wondering if it > is safe to have only one (R/O) copy of it (probably on the IPL volume), > shared by two or more LPARs? That's possible (sharing of IPL volser) as long all those LPARS are on the same z/OS level. > My SMP/E points to an entirely separate target Mod 27 and set of OMVS > files. These are cloned after maintenance to alternating IPL and maintenance > level OMVS files. What is your catalog setup? Do you have separate master catalogs and their own set of user catalogs? Or are you sharing your catalogs? I believe it is safe to share a Read Only OMVS dataset, unless you have something to prevent sharing of such OMVS datasets, for example having a folder which is written to. Of course, moving from z/OS v1.13 to 2.1 requires two different IPL volsers during rolling upgrades. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFE to enhance GDGORDER in JCL
Robert A. Rosenberg wrote: >>Could work, but it is not always known that there are indeed 5 generations. >>Lizette wants the oldest and the access method should find that oldest entry >>no matter what the quantity of versions there are. >I may not have worded my comment correctly. All I was saying was that in a GDG >with 5 generations, going DSN=GDGBASE,GDGORDER=FIFO was the equivalent of a >concatenation using relative generation numbers and listing them in oldest >(-4) to newest (0) generation number. I also noted (or implied) that this >method relieves the user from knowing the number of generations currently in >use. Many thanks for kindly explaining this. I am fully with you on this one. Perhaps I also worded my comment incorrectly, but this is IBM-MAIN where each person is kindly helping others. Thanks Robert for your kind explanation. I value your posts and I learn from them too. All of the very best for you! Groete / Greetings Elardus Engelbrecht Today I learned something new: I am *NOT* using Google anymore, because my wife always knows everything and is always right... *sigh* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
On Wed, 13 Jan 2016 22:30:19 -0500, David S. wrote: >Paul Gilmartin wrote: > >> Does OPTCD=Q work on all device types? >> I had got the impression it applied only to tapes. > >Yes, tape is implicit. OPTCD=Q only works with tape. >ASCII conversion topic in "z/OS DFSMS: Using Magnetic Tapes": >http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2m320/3.7.1 > But does mere mention of OPTCD=Q mean its use is restricted to tapes? Might not it apply to other device types? (It's hard to prove a negative) But if it's so restricted it's another instance of IBM's implementing a useful facility at the wrong layer. ASCII<->EBCDIC conversion is surely useful on other device types. Is this software in the OS or microcode in the control unit? And what about CCSID. According to the documentation, this: //STEP3 EXEC PGM=IEBGENER,CCSID=1047 //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT2DD PATHMODE=(SIRUSR,SIWUSR), // PATHOPTS=(OCREAT,OTRUNC,OWRONLY), // CCSID=1209, // PATH='&OBFUSC/work/tmp/UTF-8' //SYSUT1DD * This is a UNIX UTF-8 test. cent: "¢" //* ... should write SYSUT2 in UTF-8, yet it seems to write EBCDIC. Or am I overlooking yet another restriction? But at the very least, if it's supposed to not work it should fail with an error message. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
Paul Gilmartin wrote: > Does OPTCD=Q work on all device types? > I had got the impression it applied only to tapes. Yes, tape is implicit. OPTCD=Q only works with tape. ASCII conversion topic in "z/OS DFSMS: Using Magnetic Tapes": http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2m320/3.7.1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RESTORE JOB on z/OS 2.1 Serverpac failing
To be fair, I ordered towards the end of September. Just didn't get working on the install until now. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of David G. Yeager > Sent: Wednesday, January 13, 2016 2:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RESTORE JOB on z/OS 2.1 Serverpac failing > > I had a PMR opened in August, they gave me a workaround which I used. > They said they were working on a fix, guess they are still working on it. > > "... > Due to recently added IFREQs, the ServerPac RESTORE job is not getting > generated correctly, causing the errors. ServerPac development is > currently in the process of fixing the RESTORE job generation error. As > a workaround, you can RESTART the job from step UCLIN, removing all > updates which were already done the previous run and also removing the > statement DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)). > I hope this helps. Feel free to contact us if you need more support. ..." > > > -- > 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: DYNDISP in XCF
DYNDISP has been around for many years. The primary use/need is the case where two sysplexes share a CF engine. Once upon a long time ago, all CMOS engines were very slow, so it was common to have a lot of them. A sandbox sysplex--which we have long been blessed to own--would not be entitled to very many CF MIPS. It was easy in the early days to give a sandbox exclusive use of one or two slow CF engines. As time went by, all CMOS engines including CFs got way bigger, faster--and more expensive. To the point, in the mind of many customers, where even a single engine was had to justify for a sysprog plaything. So sharing an engine between, say, Development and sandbox made more sense. But because of the way CFCC code works, engine sharing was discouraged by IBM. Then came DYNDISP, which made sharing less unreasonable. In our configuration, the sandbox is set for dynamic dispatch, which deprecates sandbox performance at the expense of Development but still allows the sandbox to lumber along. Meanwhile, because of its preferred status, Development also gets what it needs. If you have a similar configuration, I recommend DYNDISP or its younger descendant 'thin interrupts', which appears to improve sharers' performance even more. If you do not share CF engines among sysplexes, then you don't need DYNDISP or thin interrupts. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Nathan Astle > Sent: Wednesday, January 13, 2016 09:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] DYNDISP in XCF > > Hi > > Are there in group who have enabled DYNDISP in coupling facility ? > > What advantages are enabling this feature ? > > Any comments or thoughts ? > > Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RESTORE JOB on z/OS 2.1 Serverpac failing
I had a PMR opened in August, they gave me a workaround which I used. They said they were working on a fix, guess they are still working on it. "... Due to recently added IFREQs, the ServerPac RESTORE job is not getting generated correctly, causing the errors. ServerPac development is currently in the process of fixing the RESTORE job generation error. As a workaround, you can RESTART the job from step UCLIN, removing all updates which were already done the previous run and also removing the statement DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)). I hope this helps. Feel free to contact us if you need more support. ..." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler Boot Camp at SHARE Academy in San Antonio
I'm very happy to see this as well. I saw Mike in Chicago at the Scheduling Summit and had the impression then that the Bootcamp was not happening. At least one of my colleagues may make it to San Antonio for this event alone. Thanks! . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of John Ehrman > Sent: Wednesday, January 13, 2016 12:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Assembler Boot Camp at SHARE Academy in San Antonio > > Mike Stack posted this note on the ASSEMBLER-LIST discussion group; it may > be interesting or useful to readers of this list. > John Ehrman > > I'm pleased to announce that the original, award-winning Assembler Boot > Camp is returning to SHARE as part of the SHARE Academy. The SHARE > meeting will be in San Antonio from February 28 - March 4, 2016. The SHARE > Academy, including the Assembler Boot Camp, will be held on a single day, > Sunday, February 28, 2016. > > More early information can be found at http://www.share.org/academy. If you > have programmers in your shop who, for example, need to maintain z/OS exits > in assembler, this is an opportunity for them to acquire the basic groundwork > toward that end. The ABC is focused on providing a fundamental > understanding, so that the attendees will be capable of extending their > knowledge independently. > > On a personal note, I couldn't be more pleased to return to my favorite topic, > along with my very favorite co-instructor, John Ehrman, the "father" of the > High Level Assembler. I last presented the ABC in 2009 (I'm retired, doncha > know), and adjusting to giving all the sessions in one day - and with > widescreen slides! - has been a nice challenge. All of us look forward to > teaching hungry young minds (!), so please pass this announcement along to > anyone you believe may be interested. > > All the best, and Happy New Year! > Mike > > Michael Stack > http://www.kcats.org -- 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(&CHK,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: Why doesn't "="option work in SMP/E panels?
On 13 January 2016 at 13:37, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > In most ISPF panels I can type "=option" to move quickly to another panel. > However, in the SMP/E panels, such as "=3.4" gets me not to DSLIST, but > to an "Enter only those selections specified" message. It's not unique to SMP/E - IPCS and ISMF behave the same way, but others such as SDSF and RACF don't. It can be useful either way, e.g. in IPCS to go from browsing storage to looking at the trace table using "=2.7.4". A matter of chacun à son gout. > Grrr. Is there a workaround? In fact, can I get out of SMP/E by any means > other than repeatedly entering the END command? 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. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Assembler Boot Camp at SHARE Academy in San Antonio
Mike Stack posted this note on the ASSEMBLER-LIST discussion group; it may be interesting or useful to readers of this list. John Ehrman I'm pleased to announce that the original, award-winning Assembler Boot Camp is returning to SHARE as part of the SHARE Academy. The SHARE meeting will be in San Antonio from February 28 - March 4, 2016. The SHARE Academy, including the Assembler Boot Camp, will be held on a single day, Sunday, February 28, 2016. More early information can be found at http://www.share.org/academy. If you have programmers in your shop who, for example, need to maintain z/OS exits in assembler, this is an opportunity for them to acquire the basic groundwork toward that end. The ABC is focused on providing a fundamental understanding, so that the attendees will be capable of extending their knowledge independently. On a personal note, I couldn't be more pleased to return to my favorite topic, along with my very favorite co-instructor, John Ehrman, the "father" of the High Level Assembler. I last presented the ABC in 2009 (I'm retired, doncha know), and adjusting to giving all the sessions in one day - and with widescreen slides! - has been a nice challenge. All of us look forward to teaching hungry young minds (!), so please pass this announcement along to anyone you believe may be interested. All the best, and Happy New Year! Mike Michael Stack http://www.kcats.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.1 and FONTS; Moving from z/OS 1.13
I have a small shop, 4 monoplex LPARs, no GRS. Very careful sharing of a limited set of disks including the system resident (IPL) volume, a Mod-27. Up until now, I have made separate (R/O) copies of the ROOT and other system ZFS/HFS(s) for each LPARs. This new Unix filesystem with FONTS is not small and I am wondering if it is safe to have only one (R/O) copy of it (probably on the IPL volume), shared by two or more LPARs? My SMP/E points to an entirely separate target Mod 27 and set of OMVS files. These are cloned after maintenance to alternating IPL and maintenance level OMVS files. Dave Gibney Information Technology Services Washington State University -- 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?
ISMF also keeps you in their menus. I often enter =x;3;4 to go to the DSN list. On Wed, Jan 13, 2016 at 12:50 PM, Pommier, Rex wrote: > "=x" on the command line? > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Wednesday, January 13, 2016 12:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Why doesn't "="option work in SMP/E panels? > > In most ISPF panels I can type "=option" to move quickly to another panel. > However, in the SMP/E panels, such as "=3.4" gets me not to DSLIST, but > to an "Enter only those selections specified" message. > > Grrr. Is there a workaround? In fact, can I get out of SMP/E by any means > other than repeatedly entering the END command? > > Thanks, > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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?
The SMP/E Primary Option Menu is coded with "&ZPRIM = YES". The ISPF "RETURN" command (and its companion, "=") returns control to the immediately-preceding primary options menu. Let's say you're in Sysmod Management panel, for example. If you enter "=3", you'll move to the SMP/E Query Selection Menu, not the ISPF Utility Selection panel. -- 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?
"=x" on the command line? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, January 13, 2016 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why doesn't "="option work in SMP/E panels? In most ISPF panels I can type "=option" to move quickly to another panel. However, in the SMP/E panels, such as "=3.4" gets me not to DSLIST, but to an "Enter only those selections specified" message. Grrr. Is there a workaround? In fact, can I get out of SMP/E by any means other than repeatedly entering the END command? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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?
Why not just hit PF2 to split your screen! Then you can toggle between SMP/E and normal ISPF? Just a suggestion. Bill J. On Wednesday, January 13, 2016 1:37 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: In most ISPF panels I can type "=option" to move quickly to another panel. However, in the SMP/E panels, such as "=3.4" gets me not to DSLIST, but to an "Enter only those selections specified" message. Grrr. Is there a workaround? In fact, can I get out of SMP/E by any means other than repeatedly entering the END command? Thanks, gil -- 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
Why doesn't "="option work in SMP/E panels?
In most ISPF panels I can type "=option" to move quickly to another panel. However, in the SMP/E panels, such as "=3.4" gets me not to DSLIST, but to an "Enter only those selections specified" message. Grrr. Is there a workaround? In fact, can I get out of SMP/E by any means other than repeatedly entering the END command? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CBT File 874 TSO HELP
Hi Folks, A little-known resource for access to (i.e. finding out about) useful commands and programs is CBT File 874, a TSO HELP file for some very useful commands and programs. Some of these programs do things, the likes of which are hard to find elsewhere, especially among FREE programs. ISPF statistics in the pds will tell you which CBT File contains that version of the command, which the help is for. The Updates page of the CBT Tape web site (www.cbttape.org) currently contains the latest version of File 874. "A word to the wise is sufficient." Best of everything to all of you.. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DYNDISP in XCF
Hi Are there in group who have enabled DYNDISP in coupling facility ? What advantages are enabling this feature ? Any comments or thoughts ? Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFE to enhance GDGORDER in JCL
At 00:38 -0600 on 01/13/2016, Elardus Engelbrecht wrote about Re: RFE to enhance GDGORDER in JCL: >IOW: //GDG DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5 generations yields: Could work, but it is not always known that there are indeed 5 generations. Lizette wants the oldest and the access method should find that oldest entry no matter what the quantity of versions there are. I may not have worded my comment correctly. All I was saying was that in a GDG with 5 generations, going DSN=GDGBASE,GDGORDER=FIFO was the equivalent of a concatenation using relative generation numbers and listing them in oldest (-4) to newest (0) generation number. I also noted (or implied) that this method relieves the user from knowing the number of generations currently in use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BCPii setup questions
I'm trying to setup BCPii. I did some RTFM, but still have questions. What I achieved is communication with SE: HWI007I BCPII IS ATTEMPTING COMMUNICATION WITH THE LOCAL CENTRAL PROCESSOR COMPLEX (CPC). HWI001I BCPII IS ACTIVE. However I have problems with security. 1. How to assign userid to HWIBCPII address space? Regular profile (HWIBCPII.*) in STARTED class doesn't work. Note: I'm asking about HWIBCPII, not HWISTART. 2. I was trying to use some HCD facilities requiring BCPii, got "8 0F02" (not enough authority) but no ICH408I occured in syslog. Is it normal? 3. What authorities should have HWIBCPII user? As far as I understand BCPii user must be authorized to various HWI.nnn profiles in FACILITY class, but no clue about BCPii address space reqirements. Other questions: 4. What can I do with IBM products/features using BCPii? I'm aware of Parallel Sysplex (SSDPP), CPM and HCD. For HCD I found only the option 2.11.V (Build and manage S/390 microprocessor IOCDSs and IPL attributes - Work with CPC images), which is not very useful. 5. I only used BCPii on local CPC. Can I use BCPii to query/manage other machine? How? Is it enough to define HWI.TARGET.IBM390PS.P0012345 profile with proper SNMP string? What about LPAR security? Regards -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
On Wed, 13 Jan 2016 08:51:47 -0500, David S. wrote: >... >If the data is *all* in character format, then conversion from ASCII to >EBCDIC is easy using OPTCD=Q on the DCB. > Does OPTCD=Q work on all device types? I had got the impression it applied only to tapes. There's also lately a CCSID option on both the EXEC statement and the DD statement which seems to be intended to convert between any CCSID used by the program and another CCSID appearing in a file. IIRC, I tried it and didn't get expected results. Perhaps I overreached with something such as: //SETPEXEC PGM=IEBGENER,CCSID=1047 //SYSUT2 DD CCSID=1209,PATH='...',.. (UTF-8) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.
I checked with someone in ServerPac design, and this is indeed what's up. They will look at the alternatives for solving this, including the one below. John Eells wrote: So...I infer, perhaps incorrectly, that the RESTORE job is also doing a ZONEMERGE for the SDSF zone. If that's the case, it has to do special processing to make sure that CIFREQ entries are correctly merged with SYSMOD entries that actually represent installed FMIDs. Can someone confirm that that's what's happening? If so...in z/OS V2.2 we are adding function to SMP/E to handle this directly, and as the SMP/E FMID has not been updated since z/OS V1.13 we can ask ServerPac Development to look at using this function, when available. Here's the announcement text: z/OS V2.2 SMP/E is designed to enhance ZONEMERGE command processing. A new CHECK operand for the ZONEMERGE command is intended to identify conditions that would prevent a successful ZONEMERGE. Also, ZONEMERGE processing is now designed to both enforce and preserve conditional requisites while merging target and distribution zones. This new function, planned to be available first quarter 2016 with the PTF for APAR IO23466, is intended to help you merge SMP/E zones for different products in some cases in order to consolidate product sets and simplify overall software management. Lopez, Sharon wrote: This is the answer from IBM; just in case anyone else might be experiencing this: Due to recently added IFREQs, the ServerPac RESTORE job is not getting generated correctly, causing the errors. ServerPac development is currently in the process of fixing the RESTORE job generation error. As a workaround, you can RESTART the job from step UCLIN, removing all updates which were already done the previous run and also removing all occurences of statement DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)). -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
"... conversion utility or compiler directive to make the translation from the Unisys implementation of Cobol FD's to Enterprise Cobol?" If the data is *all* in character format, then conversion from ASCII to EBCDIC is easy using OPTCD=Q on the DCB. Unfortunately, that's seldom the case, which makes things *much* more complicated. You mention the half-byte alignment problem, so you're already aware of that one. There's also the issue of how signed and unsigned decimal fields are handled (Unisys=leftmost position or none, IBM=rightmost position always). MCP was inherited from the Burroughs side of the Unisys family, so there will likely be some detailed information on the proprietary data types somewhere here: http://bitsavers.trailing-edge.com/pdf/burroughs Wish I could be more specific, but my depth of expertise is more on the IBM side. If anyone can point to a *specific* reference for Burroughs/Unisys data types, please post it here. I'd love to see it! There was a recent discussion of specific Unisys to IBM conversion issues on the "Mainframe Assembler Professionals" LinkedIn group, here: http://www.linkedin.com/groups/1462937/1462937-6049636244294488065 BFX was mentioned (a Netex product), was mentioned as a solution, and the person posting sounded very positive about it, but looking at their documentation, I don't see a reference which specifically says it does Unisys to IBM conversion - z/OS to Unisys, yes, but not the other way around: http://www.netexsw.com/nesi/support/ReleasedDocs/H21x/man-ref-H211-08.pdf And if it is supported, it looks like you basically write the conversion code yourself, in Assembler, around which BFX is basically just a "wrapper". For a fee, there are some companies which can do the conversion for you, such as: http://www.discinterchange.com > Date:Tue, 12 Jan 2016 16:04:58 + > From:"Ambros, Thomas" > Subject: Conversion from Unisys Cobol file definitions to zOS > > My apologies if there is a Cobol listserv that I should have subscribed to > and submitted the question there, if someone knows of it please let me know > so I can redirect to the correct place. > > Pardon me, also, if I use terms incorrectly in phrasing my question > because I couldn't be weaker in application programming or Cobol > idiosyncracies. > > Our site has occasion to import files from a Unisys site running 'MCP > Level 57 Miser level 15.2', and integrate the data with the application > datasets on the local system. I do not know the Cobol product the Unisys > site is using, I have inquiries out but no answers yet. There are at least > a few items causing our application programmers some difficulties. > > For example, it appears that the COMP fields in the Unisys file do not > occupy storage the same as they do on zOS. For example, a COMP field with > three digits occupies one and one-half bytes on the Unisys file whereas on > zOS it would be a halfword. > > Given the size and number of the files and descriptions to convert, coding > a conversion by hand is not entirely practical. > > I realize this is a pretty vague request, but does anyone know of a > conversion utility or compiler directive to make the translation from the > Unisys implementation of Cobol FD's to Enterprise Cobol? I have done some > basic Google searching but nothing I find appears to address this sort of > thing very closely. > > Thomas Ambros > zEnterprise Operating Systems > zEnterprise Systems Management > 518-436-6433 > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.
So...I infer, perhaps incorrectly, that the RESTORE job is also doing a ZONEMERGE for the SDSF zone. If that's the case, it has to do special processing to make sure that CIFREQ entries are correctly merged with SYSMOD entries that actually represent installed FMIDs. Can someone confirm that that's what's happening? If so...in z/OS V2.2 we are adding function to SMP/E to handle this directly, and as the SMP/E FMID has not been updated since z/OS V1.13 we can ask ServerPac Development to look at using this function, when available. Here's the announcement text: z/OS V2.2 SMP/E is designed to enhance ZONEMERGE command processing. A new CHECK operand for the ZONEMERGE command is intended to identify conditions that would prevent a successful ZONEMERGE. Also, ZONEMERGE processing is now designed to both enforce and preserve conditional requisites while merging target and distribution zones. This new function, planned to be available first quarter 2016 with the PTF for APAR IO23466, is intended to help you merge SMP/E zones for different products in some cases in order to consolidate product sets and simplify overall software management. Lopez, Sharon wrote: This is the answer from IBM; just in case anyone else might be experiencing this: Due to recently added IFREQs, the ServerPac RESTORE job is not getting generated correctly, causing the errors. ServerPac development is currently in the process of fixing the RESTORE job generation error. As a workaround, you can RESTART the job from step UCLIN, removing all updates which were already done the previous run and also removing all occurences of statement DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)). -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
