Re: TSO/ISPF Screen Swap - remoarks
The exec uses a panel to execute the swap list command. This PSEUDOPAN is a member in your ISPPLIB conncatanation which has a )Body and )END sections only. Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: Itschak Mugzach [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 7:39 AM To: 'IBM Mainframe Discussion List' Subject: RE: TSO/ISPF Screen Swap Here is the RE#xx exec to swap between logical screens based on application name rather then its number. Enjoy. | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: | Itschak Mugzach | Web: www.Securiteam.co.il | /* REXX */ /**/ /**/ /* SWAP TO SDSF */ /* THIS (SMALL) PROGRAM INVOKES AS AN ISPF COMMAND. IT WILL LOOK AT */ /* THE ISPF SWAP LIST TABLE AND LOOK TO SEE IF SDSF IS ALREADY STARTED*/ /* IF SDSF IS STARTED, IT WILL SWAP TO SDSF. OTHERWISE, IT WILL START */ /* SDSF IN A NEW LOGICAL SCREEN. */ /* THE PROGRAM WAS DEVELOPED BY ITSCHAK MUGZACH FROM SECURITEAM SOFTWA*/ /*AS A SAMPLE TO AZRIEL SNIR. */ /* (C) SECURITEAM SOFTWARE 2006. */ /**/ /* TRACE R */ SWAPTOSDSF: SIGNAL SWAPTOSDSF.CONFIG TRACE ALL SWAPTOSDSF.DOC: SWAPTOSDSF.CONFIG: PSEUDOPAN = ISRTSO /* PSEUDO PANEL TO DISPLAY */ SDSFAPPL = ISF/* SDSF APPLID */ MAXAPPLS = 8/* MAX LOGICAL SCREENS TO CHK*/ SWAPTOSDSF.CONST: STS0001E = 'STS0001E SCREEN IMAGE NOT FOUND' STS0002I = 'STS0002I MYSWAPTOSDSF OPTIONS SELECTED: ' STS0003I = 'STS0003I STATUS FOR DEVICE ADDRESS ' DISPLY4 = 'COMMAND NOT FOUND' DISPLY8 = 'END OR RETURN COMMAND ENTERED' DISPLY12 = 'PANEL, MESSAGE, OR CURSOR FIELD COULD NOT BE FOUND' DISPLY16 = 'DATA TRUNCATION OR TRANSLATION ERROR' DISPLY20 = 'SEVERE ERROR.' SELECT4 = 'RETURN COMMAND ENTERED FROM SELECTED MENU OR FROM', 'OR FROM LOWER LEVEL PANEL.' SELECT8 = 'INVALID FOR SELECT PANEL COMMAND.' SELECT12 = 'THE PANEL COULD NOT BE FOUND.' SELECT16 = 'TRUNCATION ERROR IN STORING ZCMD OR ZSEL VARIABLE.' SELECT20 = 'SEVERE ERROR.' SWAPCMD = SWAP LIST;END /* SDSF APPLID */ NSWAPSDF = START S SWAPTOSDSF.VAR: INDEX = 0 SWAPTOSDSF.MAIN: ADDRESS ISPEXEC CONTROL ERRORS RETURN ADDRESS ISPEXEC CONTROL NONDISPL END NOCMD ADDRESS ISPEXEC DISPLAY PANEL(PSEUDOPAN) COMMAND(SWAPCMD) IF (RC ×= 0) THEN DO CALL ERRORHANDLER RC DISPLY STSPPRCX END ADDRESS ISPEXEC VGET (ZAPPID1 ZAPPID2 ZAPPID3 ZAPPID4) ASIS ADDRESS ISPEXEC VGET (ZAPPID5 ZAPPID6 ZAPPID7 ZAPPID8) ASIS ADDRESS ISPEXEC VGET (ZTLDID1 ZTLDID2 ZTLDID3 ZTLDID4) ASIS ADDRESS ISPEXEC VGET (ZTLDID5 ZTLDID6 ZTLDID7 ZTLDID8) ASIS DO WHILE (INDEX MAXAPPLS) INDEX = INDEX + 1 APPLIDENT = VALUE(ZAPPID||INDEX) IF (APPLIDENT = SDSFAPPL) THEN DO SWAPIDENT = SUBSTR(VALUE(ZTLDID||INDEX),1,1) SWAPSDSF = SWAP ||SWAPIDENT /* SAY 'SWAPIDENT =' SWAPIDENT */ /* SAY 'SWAPSDSF =' SWAP2SDSF */ INDEX = 99 ADDRESS ISPEXEC CONTROL NONDISPL END NOCMD ADDRESS ISPEXEC DISPLAY PANEL(PSEUDOPAN) COMMAND(SWAPSDSF) ADDRESS ISPEXEC CONTROL NOCMD END END IF (INDEX ×= 99) THEN DO ADDRESS ISPEXEC CONTROL NONDISPL END ADDRESS ISPEXEC DISPLAY PANEL(PSEUDOPAN) COMMAND(NSWAPSDF) END EXIT /* -END OF -*/ ERRORHANDLER: SIGNAL HANDLEDAILS.CONS TRACE ALL ERRORHANDLER.DOC: /*---*/ /* */ /* APPLICATION ERROR HANDLER*/ /*GENERATE ERROR MESSAGES CALL CLEANUP */ /* (C) COPYWRITE SECURITEAM SOFTWARE LTD 2006 */ /*---*/ ERRORHANDLER.CONS: NOP ERRORHANDLER.VAR: NOP ERRORHANDLER.MAIN: ARG RCX FUNC PARM1 SAY 'STSD' VALUE(FUNC||RC) EXIT RC END /*---*/ /* TRACE R*/ /*
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
Bobbie Justice [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... green screen is still working okay. (thank goodness) Which IBMLINK are you all complaining about? The (green screen?) 3270 interface to DIALIBM (as it was called here)? This interface, via ATT, was shut down here many years (10 or so) ago and since then we work with the Web interface. This sometimes has its little problems but certainly not to the extent that I see all the IBMLINK complaints about. Kees. ** 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
Barbara Nitz wrote: Even a complete disaster on the first test is a success, under the covers. It will point out the flaws in the plan, and the items that are missing. To warm up (is that an English expression?) an old argument: The above *assumes* that it is a 'real' test, as in Let's take down the system on the fly and see if it comes up again. I have seen this done once, and it really pointed out a lot of problems that we could then fix. Unfortunately, the going practise is to test DR by doing an orderly shutdown first and then just re-IPL in the other location. In my opinion, this just tests that you defined hardware (and maybe some infrastructure in iplparm/loadxx/ieasysxx) correctly), but it is not a DR test. There is another possibility: to cut the wire (remote copy link) and have everything on remote site as the primary site would blown up. However even such test is not realistic enough. Reason: rolling disaster. In real world your machines can be destroyed one after another. The delta can be sometimes minutes, sometimes less than second, however it is extremely important for data consistency. My €0.02: 1. Data consistency!!! 2. DR is NOT EQUAL to mainframe is up and ready. You (your business) needs *complete solution*, possibly including small funny Windows/Linux servers that we don't like and don't care. From my experience I could say that having mainframe working on DR site is piece of cake, when compared to the rest of infrastructure. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
web ibmlink. The green screen works just fine, thank you very much. . The many web identity issues with web ibmlink have been well documented. - Original Message - From: Vernooy, C.P. - SPLXM [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, July 16, 2008 3:21 AM Subject: Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO Bobbie Justice [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... green screen is still working okay. (thank goodness) Which IBMLINK are you all complaining about? The (green screen?) 3270 interface to DIALIBM (as it was called here)? This interface, via ATT, was shut down here many years (10 or so) ago and since then we work with the Web interface. This sometimes has its little problems but certainly not to the extent that I see all the IBMLINK complaints about. Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
Works good here. It usually does when I read complaints, that's why I wondered which interface the complains were about. Kees. Bobbie Justice [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... web ibmlink. The green screen works just fine, thank you very much. . The many web identity issues with web ibmlink have been well documented. - Original Message - From: Vernooy, C.P. - SPLXM [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, July 16, 2008 3:21 AM Subject: Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO Bobbie Justice [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... green screen is still working okay. (thank goodness) Which IBMLINK are you all complaining about? The (green screen?) 3270 interface to DIALIBM (as it was called here)? This interface, via ATT, was shut down here many years (10 or so) ago and since then we work with the Web interface. This sometimes has its little problems but certainly not to the extent that I see all the IBMLINK complaints about. Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OPERLOG staging datasets out of sync in sysplex
Martin,
First remark: Operlog does not manage the staging dataset, System Logger
does. Operlog is only a user of System Logger.
If you can suffer the loss of data, you can delete the logstream and
structure (and the remaining staging datasets) and recreate them.
Kees.
Ps. This newsgroup is a mirror of a listserver. Subscribe to the
listserver to address the entire Ibm-main population. See the info
attached automagically at the bottom.
Kees.
martin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
...
We are having problems getting our OPERLOG staging datasets back 'in
sync' after a 2 day DR test - stopping and starting OPERLOG,
deallocating and reallocating the structure and even structure
rebuilds have had no effect. We've been sysplexed since God was a boy
(in fact we were one of the first UK sites to go sysplex) but this
one's got us stumped!
Documentation on how OPERLOG manages its staging datasets, or how we
can override what generations it uses, is nonexistent as far as we can
see. If anyone can shed any light on how we sort this we'd be very
grateful - we are still on OS/390 2.10 (its a long story, don't ask)
so any 'official' IBM support has long since ceased to exist!
details follow.
Martin Jackson
Mainframe team manager
Vertex IT Operate
Grove House, Dawson House, Great Sankey
Warrington WA5 3LW
Tel: 01925 233599 / int 33599
mailto:[EMAIL PROTECTED]
-
IXCMIAPU reports OPERLOG is using gen A0017374 of the staging dataset,
status 'pending delete', even though the dataset didn't exist. We have
tried creating the dataset so OPERLOG can delete it and clear the
'pending' but what happens is it deletes it but still leaves it as the
current log stream in 'delete pending' state. It then abends next time
it tries to delete it. Its creating new generations of the staging
dataset but they are LOWER gen. numbers than the one it thinks its
using and IXCMIAPU lists them as 'orphans'
IXCMIAPU output is :-
LOG STREAM CONNECTION INFO:
SYSTEMS CONNECTED: 1
SYSTEMSTRUCTURE CON CONNECTION CONNECTION
NAME VERSION ID VERSION STATE
-- -- --
PRD1 C2B1DE6E418155C0 01 00010128Active
LOG STREAM DATA SET INFO:
DATA SET NAMES IN USE: LOGGER.SYSPLEX.OPERLOG.SEQ#
Ext. SEQ#Lowest BlockidHighest GMTHighest
Local Status
- -
-
*1 A0017374 0004B6C59819 07/05/08 09:52:51 07/05/08
10:52:51 DELETE PENDING
NUMBER OF DATA SETS IN LOG STREAM: 1
POSSIBLE ORPHANED LOG STREAM DATA SETS:
DATA SET NAMES:
LOGGER.SYSPLEX.OPERLOG.A0017215
LOGGER.SYSPLEX.OPERLOG.A0017253
NUMBER OF POSSIBLE ORPHANED LOG STREAM DATA SETS: 2
Our structure definition is :-
.DEFINE STRUCTURE NAME(LOGGER_OPERLOG)
LOGSNUM(1)
MAXBUFSIZE(4096)
AVGBUFSIZE(535)
EFFECTIVE
AVERAGE
BUFFER
SIZE(535)
DEFINE LOGSTREAM NAME(SYSPLEX.OPERLOG)
STRUCTNAME(LOGGER_OPERLOG)
LS_DATACLAS(DCLOGGER)
LS_MGMTCLAS()
LS_STORCLAS(SCSTAND)
HLQ(LOGGER)
MODEL(NO)
LS_SIZE(1000)
STG_MGMTCLAS()
STG_STORCLAS(SCSTAND)
STG_DATACLAS(DCLOGGER)
STG_SIZE(0)
LOWOFFLOAD(20)
HIGHOFFLOAD(80)
STG_DUPLEX(YES)
DUPLEXMODE(COND)
RMNAME()
DESCRIPTION()
RETPD(0)
AUTODELETE(NO)
DASDONLY(NO)
Error from IXGLOGR when it tries deleting the (nonexistent) gen
A0017374 of the staging dataset is :-
IXG251I IKJ56228I DATA SET LOGGER.SYSPLEX.OPERLOG.A0017374 NOT IN
CATALOG OR CATALOG CAN NOT BE ACCESSED
IXG063I LOGGER ABENDED AND REQUESTED AN SVC DUMP WHILE PROCESSING 450
LOGSTREAM: SYSPLEX.OPERLOG
STRUCTURE: **UNKNOWN**
MODULE=IXGI3DSC,ABEND=S01C5,REASON=0009000C
IXG301I SYSTEM LOGGER FAILED TO OFFLOAD DATA FOR LOG STREAM 451
SYSPLEX.OPERLOG IN STRUCTURE LOGGER_OPERLOG. RETURN CODE: 000C
REASON CODE: DIAG1: 001C DIAG2: 17080002 DIAG3:
0107001B DIAG4:
--
**
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,
Disappearing JES2 output
My colleague has a batch job (TSO, calling a REXX) that puts the result into systsprt: //SYSTSPRT DD SYSOUT=H,LRECL=256,RECFM=V,DEST=R720 That printer destination is CMA Spool, these days called ESF. (I am not a printer person, either.) He noticed that *some* of the output 'disappears', i.e. it does get deleted by JES2 ($HASP250 is issued), BUT the output does not appear in ESF. Unfortunately, the problem is not reproducible at will, rather it seems to be load-related: The job is submitted on system 3 to execute on system 3. ESF resides on system number2 and watches the same Spool/MAS (same sysplex). HASP250 for the 'missing' output is issued on system number 6, while the correctly in ESF arriving output gets hasp250 on system2, where ESF was reading it. In addition, ESF would output a message stating that the output arrived (ESF766), but we don't see that for the 'missing' output. Does anyone have an idea what to look for? (Given that the problem is not readily reproducible, appears to be load related *and* the output disappears, we are currently reluctant to open an ETR with IBM...) Best regards, Barbara -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OPERLOG staging datasets out of sync in sysplex
First: I only saw this because Kees quoted it. Unless you direct your output to ibm-main, I won't see any answer (and email to this address will get rejected). OW50564? That one even has fix for 2.10. Is that applied? As Kees stated, the only sure way to get out of the error will be to delete the operlog logstream, delete the structure, make sure all traces are gone (check that neither staging nor offload datasets for operlog are around anywhere, if necessary, delete them manually). Then redefine the structure in CFRM, redefine the logstream, turn operlog back on. Regards, Barbara Nitz -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Serverpac Divergence?
Dave, I'm like you. I do the software upgrade process, and after UP, and the dataset RESTORE job, I start to jump around. I always run all the IVP's. My sincere wish is that IBM provided another alternative for the software upgrade process that was simpler(at least for me it seems simpler). My target datasets and DLIB datasets are not cataloged by design, because of our cloning process and have the same DSN's as the running datasets. However, due to the SERVERPAC process they have to be CATALOGED for a long enough period to restore them. Since Serverpac already knows the VOLSER of each of the datasets, why not give an option to allocate them all, but not catalog, and then restore to the uncataloged copies? All that would have to be done is to supply VOL=SER= on the RESTORE job. Of course this does not cover the zFS datasets, but those are unique names anyway with SYSRES volser as a qualifier. That would eliminate a bunch of steps. _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, July 15, 2008 7:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Serverpac Divergence? When (Or do you just run it all in order?) does your path for an upgrade diverge from Serverpac's jobs. Looks like I made it through UP and now I need to start skipping around. I'm doing a Software Upgrade (as I did for 1.4) and after fighting the system layout, got it close to what I want. I still wish I could do some HLQ renaming without it wanting me to define (with a serverpac job) the alias's needed and since I keep the same master catalog, it's picky there also. Now, I'd really like to look at a suggested LOAD00, but that job isn't in the software upgrade path. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooy, C.P. - SPLXM Works good here. It usually does when I read complaints, that's why I wondered which interface the complains were about. It works good probably 98% of the time. Unfortunately, in compliance with Murphy's Law, you likely don't really need it except during that other 2% of the time when it's broken. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
It's working right now. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pace Sent: Wednesday, July 16, 2008 8:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
[snip] To answer the original question: In Germany there is a requirement to *have* a DR plan, as far as I know, but no requirement to test that regularly. It is sort of implied that it needs to be tested :-) Regards, Barbara Nitz Hum, by have a plan, I assume that does not include have my resume ready and up to date. [grin] -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
On Wed, 16 Jul 2008 13:23:55 +0200, Barbara Nitz [EMAIL PROTECTED] wrote: That printer destination is CMA Spool, these days called ESF. (I am not a printer person, either.) These days it's called CA-Spool. Does anyone have an idea what to look for? Not a clue. But since we are starting to use CA-SPOOL, I hope we don't experience your problem. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
On Wed, 16 Jul 2008 08:21:37 -0400, Mark Pace [EMAIL PROTECTED] wrote: I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. It's not the place to bi*** about it, but if you are just trying to find out does it work for you?, it's a great place to verify it isn't a problem local to your site. Odd's are it isn't a local problem these days, but before you start tracking down all your local network support, it's nice to know one way or the other. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Moving the DSNs with DSS/FDR should be easy enough. You shouldn't need SMS, but hard to image that kind of volume and not SMS. You can tell DSS to move to a pool of DASD, you specify the VOLSERs and the amount of space to use. But your scenario seem more like a logical move, and recatalog, of 2-3 Mod3 to 1 Mod9 but you could move numerous MOD3 to several MOD9. If a DSN is allocated, it won't move. So a repetitive process should get them all moved. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
I understand that. And if the title were Is IBMLink up? or something similar it wouldn't be so bad. IBMLink just brutalized here ever few days. On Wed, Jul 16, 2008 at 9:15 AM, Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 16 Jul 2008 08:21:37 -0400, Mark Pace [EMAIL PROTECTED] wrote: I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. It's not the place to bi*** about it, but if you are just trying to find out does it work for you?, it's a great place to verify it isn't a problem local to your site. Odd's are it isn't a local problem these days, but before you start tracking down all your local network support, it's nice to know one way or the other. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.htmlhttp://home.flash.net/%7Emzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
Hello. I have done the same and still giving the error. Pls find the below job i have submitted. //FTPSTEP2 EXEC PGM=SORT,COND=(0,EQ,FTPSTEP1) //SORTLIB DD DSN=SORT.SORTLIB,DISP=SHR //SYSOUT DD SYSOUT=* //SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTIN DD DSN=amp;TEMPFILE, //DISP=(OLD,PASS) //SORTOUT DD DSN=amp;STEP2FTP, //DISP=(NEW,PASS,DELETE), //SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA, //DCB=(RECFM=FB,LRECL=080,BLKSIZE=8000) //SYSINDD DSN=USR.PROCLIB.INPUT(FTPSORT),DISP=SHR //* //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSOUT DD SYSOUT=X //INPUTDD * FTP.KAB.KLOUSRI.COM LMCOE lmc03 LOCSITE FWF1IENDLY CD /MAS PUT //DD:SORTOUT OUTPUT.FILE QUIT // The below is the error message that is shown EZA1460I Command: EZA1736I CD /MS8 EZA1701I CWD /MS8 250 OK. Current directory is /MS8 EZA1460I Command: EZA1736I PUT //DD:SORTOUT OUTPUT.FILE EZA1685W Invalid local file identifier EZA1460I Command: EZA1736I QUIT EZA1701I QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. Thanks, Rajeev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
Don't you need quotes around the filenames on the PUT statement? PUT '//DD:SORTOUT' 'OUTPUT.FILE' Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rajeev Sent: Wednesday, July 16, 2008 9:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP Temporary File Hello. I have done the same and still giving the error. Pls find the below job i have submitted. //FTPSTEP2 EXEC PGM=SORT,COND=(0,EQ,FTPSTEP1) //SORTLIB DD DSN=SORT.SORTLIB,DISP=SHR //SYSOUT DD SYSOUT=* //SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTIN DD DSN=amp;TEMPFILE, //DISP=(OLD,PASS) //SORTOUT DD DSN=amp;STEP2FTP, //DISP=(NEW,PASS,DELETE), //SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA, //DCB=(RECFM=FB,LRECL=080,BLKSIZE=8000) //SYSINDD DSN=USR.PROCLIB.INPUT(FTPSORT),DISP=SHR //* //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSOUT DD SYSOUT=X //INPUTDD * FTP.KAB.KLOUSRI.COM LMCOE lmc03 LOCSITE FWF1IENDLY CD /MAS PUT //DD:SORTOUT OUTPUT.FILE QUIT // The below is the error message that is shown EZA1460I Command: EZA1736I CD /MS8 EZA1701I CWD /MS8 250 OK. Current directory is /MS8 EZA1460I Command: EZA1736I PUT //DD:SORTOUT OUTPUT.FILE EZA1685W Invalid local file identifier EZA1460I Command: EZA1736I QUIT EZA1701I QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. Thanks, Rajeev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
Rajeev You need a SORTOUT DD statement on your FTP step (referring to the file created on the SORTOUT DD in your SORT step). (Also, you might want to make sure you remove the login and password details from your FTP input stream when posting it to a public forum such as this) Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Rajeev Sent: 16 July 2008 14:35 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP Temporary File Hello. I have done the same and still giving the error. Pls find the below job i have submitted. //FTPSTEP2 EXEC PGM=SORT,COND=(0,EQ,FTPSTEP1) //SORTLIB DD DSN=SORT.SORTLIB,DISP=SHR //SYSOUT DD SYSOUT=* //SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTIN DD DSN=amp;TEMPFILE, //DISP=(OLD,PASS) //SORTOUT DD DSN=amp;STEP2FTP, //DISP=(NEW,PASS,DELETE), //SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA, //DCB=(RECFM=FB,LRECL=080,BLKSIZE=8000) //SYSINDD DSN=USR.PROCLIB.INPUT(FTPSORT),DISP=SHR //* //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSOUT DD SYSOUT=X //INPUTDD * FTP.KAB.KLOUSRI.COM LOCSITE FWF1IENDLY CD /MAS PUT //DD:SORTOUT OUTPUT.FILE QUIT // The below is the error message that is shown EZA1460I Command: EZA1736I CD /MS8 EZA1701I CWD /MS8 250 OK. Current directory is /MS8 EZA1460I Command: EZA1736I PUT //DD:SORTOUT OUTPUT.FILE EZA1685W Invalid local file identifier EZA1460I Command: EZA1736I QUIT EZA1701I QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Serverpac Divergence?
ServerPac trick of the day: - Take the full-system replacement path - Generate the jobs - Save them for reference - Go back and take the Software Upgrade path, using the stuff you saved as you wish... Gibney, Dave wrote: snip Now, I'd really like to look at a suggested LOAD00, but that job isn't in the software upgrade path. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Serverpac Divergence?
OK, *two* ServerPac tips today (don't get used to this... ;-): If you want uncataloged data sets: - Create a new catalog for the installation - Discard it afterwards Jousma, David wrote: snip My sincere wish is that IBM provided another alternative for the software upgrade process that was simpler(at least for me it seems simpler). My target datasets and DLIB datasets are not cataloged by design, because of our cloning process and have the same DSN's as the running datasets. However, due to the SERVERPAC process they have to be CATALOGED for a long enough period to restore them. Since Serverpac already knows the VOLSER of each of the datasets, why not give an option to allocate them all, but not catalog, and then restore to the uncataloged copies? All that would have to be done is to supply VOL=SER= on the RESTORE job. Of course this does not cover the zFS datasets, but those are unique names anyway with SYSRES volser as a qualifier. That would eliminate a bunch of steps. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
Did the 'missing' output ever really exist? Perhaps the application opened the file but never actually wrote anything. ;-) My top five 'usual suspects': 1. Application program 2. Application program 3. Application programmer 4. Disturbances in the force. 5. Some combination of the above. If you can somehow be satisfied the application is actually doing as alleged, then I'd take a look at the SMF/RMF data to get some idea why JES did what it did. HYH and good luck -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barbara Nitz Sent: Wednesday, July 16, 2008 6:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Disappearing JES2 output My colleague has a batch job (TSO, calling a REXX) that puts the result into systsprt: //SYSTSPRT DD SYSOUT=H,LRECL=256,RECFM=V,DEST=R720 That printer destination is CMA Spool, these days called ESF. (I am not a printer person, either.) He noticed that *some* of the output 'disappears', i.e. it does get deleted by JES2 ($HASP250 is issued), BUT the output does not appear in ESF. Unfortunately, the problem is not reproducible at will, rather it seems to be load-related: The job is submitted on system 3 to execute on system 3. ESF resides on system number2 and watches the same Spool/MAS (same sysplex). HASP250 for the 'missing' output is issued on system number 6, while the correctly in ESF arriving output gets hasp250 on system2, where ESF was reading it. In addition, ESF would output a message stating that the output arrived (ESF766), but we don't see that for the 'missing' output. Does anyone have an idea what to look for? (Given that the problem is not readily reproducible, appears to be load related *and* the output disappears, we are currently reluctant to open an ETR with IBM...) Best regards, Barbara -- NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
Barbara Nitz asked: //SYSTSPRT DD SYSOUT=H,LRECL=256,RECFM=V,DEST=R720 What are the (default) characteristics of SYSOUT CLASS H? Anything special, or different than whatever the MSGCLASS of the JOB is? He noticed that *some* of the output 'disappears', Is the output that does NOT disappear also SPOOLed to SYSOUT CLASS H? Is that (non-disappearing) output also DESTed to R720? Does anyone have an idea what to look for? Here are some things you could try. Possibly there's at least one that is more convenient than the others: 1. Look at the SMF records for one of the JOBs that had its output disappear. Compare these to those for one whose output did NOT disappear. Anything interesting? 2. Use an // OUTPUT statement to direct the output to more than one destination/location/class/etc. When the output directed to DEST=R720 disappears does the other output get written/printed/whatever? 3. Change the //SYSTSPRT DD statement to send the output to an ordinary data set. Does the data set actually get anything written into it? 4. Compare the SMF records written for a JOB which had the changes in items 2 and 3, above, to those for a JOB which had its output disappear (or to one whose output did not disappear). I would try #2 first, since it requires so little effort, and also (if you direct the second set of output to some place that does not get printed immediately) leaves the entire JOB on the SPOOL for you to examine using IOF (if you have that) [I don't know if SDSF lets you take a look at the relevant JES2 control blocks for a JOB or not]. I predict one that you will find that no records are, in fact, being written to the SYSTSPRT file in those cases where the output is (supposedly) disappearing. Why? The JES2 and CA-SPOOL messages you report suggest that there is simply no output being picked up by CA-SPOOL in the first place, and JES2 then purges the JOB after all that was, in fact, produced is processed. It is very unlikely that there is a bug in CA-SPOOL that would cause it to eat output WITHOUT the usual message that the output which it subsequently eats arrived in the first place. Just guessing of course, but if you were closer, I would bet a cup of coffee from the breakroom on the outcome of your investigation. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Yes, they do, but we don't have them. We do have TDMF, though. Jon snip Innovation Software ( FDR ) has some slick products to do this. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
No, actually I'm looking to move one 3390-3 to one 3390-9. These particular volumes are pretty much full and it's starting to cause us application problems. The application in question has its own means of parceling out which data sets go where. I would much prefer to move these things a volume at a time rather than a file at a time. Changing all the volumes to be SMS-managed and putting them in pools would be the best solution, but there are a couple of minor reasons I don't want to put any effort into that if I can simply move some of them to mod 9s and be done with it for a while. SMS management of these volumes will come, though. Oh yes, it will come. Jon snip Moving the DSNs with DSS/FDR should be easy enough. You shouldn't need SMS, but hard to image that kind of volume and not SMS. You can tell DSS to move to a pool of DASD, you specify the VOLSERs and the amount of space to use. But your scenario seem more like a logical move, and recatalog, of 2-3 Mod3 to 1 Mod9 but you could move numerous MOD3 to several MOD9. If a DSN is allocated, it won't move. So a repetitive process should get them all moved. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS 1.9 SDSF PE PTF UA40949
If you have not seen this you should take a lookWe are being bitten by it .. APAR Identifier .. OA25382 Last Changed 08/07/14 AFTER OA23460, USE OF THE SDSF JDS PANEL TO MODIFY A SINGLE DATA SET ATTRIBUTE CAN RESULT IN CHANGING ALL D 08/06/04 PTF PECHANGE James (Jim) Chappell 503 745-7841 503 349-5603(cell) [EMAIL PROTECTED] Daimler Trucks North America LLC If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
snip--- To warm up (is that an English expression?) an old argument: The above *assumes* that it is a 'real' test, as in Let's take down the system on the fly and see if it comes up again. I have seen this done once, and it really pointed out a lot of problems that we could then fix. unsnip-- We always took incremental backups at several points through the day. The assumption was that we lost power, so the only recovery mechanism we had was those incremental backup tapes. We also played with XRC, from our Shark box to the remote site, with the data mover operating from the remote site. -snip Unfortunately, the going practise is to test DR by doing an orderly shutdown first and then just re-IPL in the other location. In my opinion, this just tests that you defined hardware (and maybe some infrastructure in iplparm/loadxx/ieasysxx) correctly), but it is not a DR test. --unsnip- Agreed: that's not a true disaster if you have time for an orderly shutdown. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
--snip--- DR is NOT EQUAL to mainframe is up and ready. You (your business) needs *complete solution*, possibly including small funny Windows/Linux servers that we don't like and don't care. From my experience I could say that having mainframe working on DR site is piece of cake, when compared to the rest of infrastructure. -unsnip--- Complete agreement. For us, mainframe DR was measured in hours, and fractions thereof. Windoze/Linux server recovery was measured in DAYS, and fractions thereof. Backup and recovery of all those small machines just isn't as robust and timely as what we're accustomed to on our super servers. I attribute a large part of this problem to the various vendors of the equipment. There are no standards vis-a-vis tape recording formats, no high-capacity tape gear, no standardized backup/recovery software and last but not least, no proper attitude in this direction. Management won't invest, and PFCSK's mostly just don't give a damn. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
snip-- Hum, by have a plan, I assume that does not include have my resume ready and up to date. [grin] --unsnip-- If not, it should!! (Bigger grin) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
Complete agreement. For us, mainframe DR was measured in hours, and fractions thereof. Windoze/Linux server recovery was measured in DAYS, and fractions thereof. Backup and recovery of all those small machines just isn't as robust and timely as what we're accustomed to on our super servers. Same here. We don't even try to restore the entire Windows environment. There's not enough time. The LAN people restore an application subset and test it. They assume that in a real disaster that having test each individually, then collective will work too. I attribute a large part of this problem to the various vendors of the equipment. There are no standards vis-a-vis tape recording formats, no high-capacity tape gear, no standardized backup/recovery software and last but not least, no proper attitude in this direction. Management won't invest, and PFCSK's mostly just don't give a damn. BTW - there are high capacity tape drives for distributed systems. We are using the new TS1120 encrypting drives for our distributed system backups. Our PFCSKs do care. And management does too. However, there is the ever present risk vs. cost evaluation. So, IT management may care. But our main BCP person in not even in IT. And when the President/CEO starts yelling at __him__ about costs, then the you-know-what rolls down hill. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
From a technical perspective, I completely agree. More, some important management education tends to occur. I was speaking from a purely business perspective. That is, I submit that updated resumes are appropriate unless and until there is some hard, compelling evidence that the business could actually survive a real plan execution. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Tuesday, July 15, 2008 11:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: European BCP Regulations? Even a complete disaster on the first test is a success, under the covers. It will point out the flaws in the plan, and the items that are missing. That's why we tested quarterly and kept copious notes from each test. You're going to go through multiple iterations; take it as given. But each iteration will be an improvement over the previous run. (We had the luxury of a completely separate system for our DR testing, which helps immensely!) Hal Merritt wrote: Having been up close and personal with a couple of major 'events', I feel I can safely say that every event is just like every other event in that it is unique. In other words, they are predictably unpredictable. Even full dress rehearsals just don't appease Mr Murphy. I would then argue that you can't know if your plan will actually work unless you actually test it on an ongoing basis. I would further wager a virtual beverage or two that that first real attempt will need some serious spin to be described as anything but a total disaster in and of itself. Only after several iterations will it get to the point of being a viable business alternative. After many more iterations, enough kinks get ironed out to become just another standard procedure. My $0.02 (before taxes) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bri P Sent: Tuesday, July 15, 2008 3:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: European BCP Regulations? ..snip The idea I think is to 'prove' that the DR process works - whatever you think of that. I think there are more elegant ways to prove something without actually manually working through it - mathematicians have been doing so for hundreds of years. I also think that, for something as crucial as DR, why put yourself through the risk that comes from doing these swaps? I mean, if someone was chasing you with a weapon, as a last resort, to escape them you might run across a busy freeway - and get away with it. If you did that regularly though, there's more and more chance you'll come a cropper.. Brian NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
I have used the FDR product. You can get a three month contract with them to use FDRPAS. The cost is not too high and you can move files while they are being used. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Pat Mihalec wrote: I have used the FDR product. You can get a three month contract with them to use FDRPAS. The cost is not too high and you can move files while they are being used. If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO/ISPF Screen Swap
The reason I chose X1, X2, X3 ... X9, XA is that I am just lazy. Also, I stack commands in the command area. Thus, the shorter the command string, the more I can enter. As for hitting ENTER to activate all the sessions, I have tried it and it fails. The only way to activate all sessions is to swap to the first session. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
You use LDMF (now owned by IBM...TDMF's little brother) or subcontract one of us experts to do it for you! Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] - -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 16, 2008 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Pat Mihalec wrote: I have used the FDR product. You can get a three month contract with them to use FDRPAS. The cost is not too high and you can move files while they are being used. If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
I know we moved some data from a 3390-3 to a 3390-9 without problems. It was quick, easy and painless. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Jon, I believe there are some restrictions on the use of TDMF's ICKDSF option. Volumes with OS catalogs for instance. I highly recommend refering to the Installation and Reference manual. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Tuesday, July 15, 2008 12:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Thanks, John. That's just the ticket. Jon snip You can move a mod3 to a mod9 but not three mod3 to one mod9. You need to specify ICKDSF on your options statement if you do not have AUTOMATIC ICKDSF=YES. TDMF will invoke ickdsf to refresh the vtoc to show the increased capacity on the volume(s). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Traylor, Terry Jon, I believe there are some restrictions on the use of TDMF's ICKDSF option. Volumes with OS catalogs for instance. I highly recommend refering to the Installation and Reference manual. Um, what's an OS catalog? :-) Didn't they go the way of the dinosaurs, carrier pigeons, the Edsel, Y2K, et al? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
On Wed, 16 Jul 2008 09:05:45 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Pat Mihalec wrote: I have used the FDR product. You can get a three month contract with them to use FDRPAS. The cost is not too high and you can move files while they are being used. If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? Ahhh... then you need FDRMOVE (FDRPAS the first volume, FDRMOVE the other data sets). Or TDMF + LDMF (or LDMF volume migrate + LDMF). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Mark Zelden wrote: On Wed, 16 Jul 2008 09:05:45 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? Ahhh... then you need FDRMOVE (FDRPAS the first volume, FDRMOVE the other data sets). Or TDMF + LDMF (or LDMF volume migrate + LDMF). So is all of this movement transparent to running applications? Or is only the FDRPAS/TDMF part transparent? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 16, 2008 1:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Mark Zelden wrote: On Wed, 16 Jul 2008 09:05:45 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? Ahhh... then you need FDRMOVE (FDRPAS the first volume, FDRMOVE the other data sets). Or TDMF + LDMF (or LDMF volume migrate + LDMF). So is all of this movement transparent to running applications? Or is only the FDRPAS/TDMF part transparent? This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
Thanks ..Ok i will check this and see. again about the password all it is not the real one. Thanks, Rajeev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
- Original Message - From: Jousma, David [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 1:07 PM Subject: Re: Moving 3390-3 to 3390-9 LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
OK. Operating System catalogs (ICF) as opposed to DB2 catalogs, etc. But somehow, I know you knew I was referring to the ESDS portion of the BCS. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Wednesday, July 16, 2008 9:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Traylor, Terry Jon, I believe there are some restrictions on the use of TDMF's ICKDSF option. Volumes with OS catalogs for instance. I highly recommend refering to the Installation and Reference manual. Um, what's an OS catalog? :-) Didn't they go the way of the dinosaurs, carrier pigeons, the Edsel, Y2K, et al? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Jousma, David wrote: LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. It moves data sets while applications have them OPEN? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Tom, Not true. zDMF moves allocated/in use datasets transparently, just like TDMF moves entire volumes with datasets allocated on it transparently. Kinda scary actually. _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, July 16, 2008 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 - Original Message - From: Jousma, David [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 1:07 PM Subject: Re: Moving 3390-3 to 3390-9 LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. Regards, Tom Conley This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 16, 2008 12:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Jousma, David wrote: LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. It moves data sets while applications have them OPEN? -- Edward E Jaffe http://www-935.ibm.com/services/us/index.wss/offering/gts/a1028200 quote Softek Logical Data Migration Facility (LDMF) enables you to consolidate data onto large capacity, better performing volumes without interruption to the 24 x 7 business environment. Since manual data set-level migration is complex and disruptive, Softek LDMF is designed to perform migrations while data sets remain open, so applications remain available, reducing downtime. Softek LDMF is storage vendor-independent, host-based software that enables data set migration across storage vendor arrays. /quote -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Should have added that we have the product here, and it works well. Here is the link for info for non-believers... http://www-935.ibm.com/services/us/index.wss/offering/its/a1029927 BTW, I am not affiliated with them or IBM in any employment capacity _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jousma, David Sent: Wednesday, July 16, 2008 1:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Tom, Not true. zDMF moves allocated/in use datasets transparently, just like TDMF moves entire volumes with datasets allocated on it transparently. Kinda scary actually. _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, July 16, 2008 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 - Original Message - From: Jousma, David [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 1:07 PM Subject: Re: Moving 3390-3 to 3390-9 LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RRS/DB2 JDBC definition and implementation
Hi everybody! I need your help for this: to get a detailed documentation on how to know: 1) All z/OS Resources required to implement the RRS 2) RRS detailed implementation considerations 3) RRS configuration 4) DB2 JDBC/SQLJ Driver for z/OS, with the version that belongs DB2 8, detailed implementation and configuration. (JCC) 5) How to validate WLM application environment. Date: Wed, 16 Jul 2008 10:04:01 -0700 From: [EMAIL PROTECTED] Subject: Re: Moving 3390-3 to 3390-9 To: IBM-MAIN@BAMA.UA.EDU Mark Zelden wrote: On Wed, 16 Jul 2008 09:05:45 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: If you're moving from say 99 mod-3s to 99 mod 9s, then this software does what you want. But, what if you're moving from 99 mod-3s to 33 mod-9s? Ahhh... then you need FDRMOVE (FDRPAS the first volume, FDRMOVE the other data sets). Or TDMF + LDMF (or LDMF volume migrate + LDMF).So is all of this movement transparent to running applications? Or is only the FDRPAS/TDMF part transparent? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Tenemos lo que búscas…JUEGOS. http://club.prodigymsn.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
Agreed. Another reason to consolidate on the MF. snip From my experience I could say that having mainframe working on DR site is piece of cake, when compared to the rest of infrastructure. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Using FDRPAS I found all movement, except for specific system dataset, which was only one or two, that I could not move while the system was up. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
This was not true with FDRPAS. I was able move even files for a CICS region without taking the region down. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] Pinnacle [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/16/2008 12:41 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Moving 3390-3 to 3390-9 - Original Message - From: Jousma, David [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 1:07 PM Subject: Re: Moving 3390-3 to 3390-9 LDMF - now known as zDMF(IBM purchased it), is a transparent dataset level move tool. They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: European BCP Regulations?
I was speaking from a purely business perspective. That is, I submit that updated resumes are appropriate unless and until there is some hard, compelling evidence that the business could actually survive a real plan execution. I have never seen an 'unsuccessful' DR test. The project management spin always states the test was a success, regardless of the outcome. I was involved in one where not a single database was successfully restored, no batch or online scripts ran. But, because we had a clean IPL, the test was a success. I was even brought up on the carpet for calling the test a failure. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
I have suggested IBM publish near real time and historical availability data for IBMLink. We do this internally (Web page known officially as Wall of Stability unofficially as Wall of Shame). The concept is users should have one very stable, simple place (no authentication public space) to go see current outages and past outages. If you are providing a highly available application this would be something to be proud of similar to 1527 SAFE WORK DAYS NO ACCIDENT at the factory entrance. So far this suggestion has not been met with enthusiasm. I want to see IBM build and monitor IBMLink with stock tools they sell to customers or Alpha/Beta releases in the process of going to RTM. If you are going to tell me how to build and monitor my applications you should eat your own dog food and show me how that works for you. Same goes for all the other vendors. IBMLink is a critical tool and one used by everyone here. IBM has smart, hard working people on this problem and they have spent considerable money to provide more redundant infrastructure and improve availability. They need to do better. We are crippled without IBMLink, ShopzSeries, and Resourcelink. I put in z/OS 1.9 on an LPAR this morning and we have been working several problems one of which I think we are about to open a PMR on. I don't like to think how the research to this point would have gone if I all I had was 1-800-IBM-SERV. I have seen several instances of HTTP 500 errors circumvented by existing all the browsers and starting a new one then logging back into IBMLink. I did call the help desk and was told this is fallout from yesterdays SEV1 ticket 36241384 and that 3 symptoms are being reported for a small percentage of users. HTTP 500 Server Error Entitlement page presented incorrectly Unable to process request In all the cases they know about exiting out of your browser and doing a new session with a signon has circumvented the problem. The ticket from yesterday is still open and they are still researching. Talking about IBMLink IMHO is fair game it is one of the most commonly used customer facing applications used by all system programmers for System z operating systems and subsystems. If it just worked no one would have reason to brutalize it. We talk about z/OS, SMPE, ServerPac, and IBMLink is just another tool. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pace Sent: Wednesday, July 16, 2008 9:25 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO I understand that. And if the title were Is IBMLink up? or something similar it wouldn't be so bad. IBMLink just brutalized here ever few days. On Wed, Jul 16, 2008 at 9:15 AM, Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 16 Jul 2008 08:21:37 -0400, Mark Pace [EMAIL PROTECTED] wrote: I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
- Original Message - From: Pat Mihalec [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 2:04 PM Subject: Re: Moving 3390-3 to 3390-9 This was not true with FDRPAS. I was able move even files for a CICS region without taking the region down. Apples and oranges. FDRPAS is full-volume and we all know that works. We're talking dataset level moves. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Jousma, David wrote: Should have added that we have the product here, and it works well. Here is the link for info for non-believers... http://www-935.ibm.com/services/us/index.wss/offering/its/a1029927 Pretty slick! I was aware of the FDRPAS approach, which leverages the operating system's DDR SWAP logic. I was unaware that similar functionality could be had at the data set level. I wonder how they do it? And, if data can be moved while OPEN with data-set-level granularity, why use products that offer only volume-level granularity? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
It moves data sets while applications have them OPEN? Yes and No is my understanding.It moves the data so I/O is directed to the new location, but the move isn't committed until the ENQ is released. FDRMOVE, which we've used, works the same way. From the LDMF manual... 7. Completion phase Although the metadata has been modified, applications that were active before diversion will have their I/O redirected to the target location until they de-allocate the data set. For applications that continue to have the original source file allocation, a scheduled bounce will be required in order to free the original space Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 16, 2008 1:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 Jousma, David wrote: Should have added that we have the product here, and it works well. Here is the link for info for non-believers... http://www-935.ibm.com/services/us/index.wss/offering/its/a1029927 Pretty slick! I was aware of the FDRPAS approach, which leverages the operating system's DDR SWAP logic. I was unaware that similar functionality could be had at the data set level. I wonder how they do it? And, if data can be moved while OPEN with data-set-level granularity, why use products that offer only volume-level granularity? -- Edward E Jaffe Remote replication? My guess is that replicating an entire volume would have less overhead than doing each dataset on the volume separately. I'd likely use TDMF/FDRPAS when moving from one storage array to a new one, if the volumes were the same size. Using LDMF might be nice for consolidating from multiple, smaller, volumes to a larger volume (like the -3 to -9 in the subject). I would guess that using LDMF to move a dataset requires that the dataset be recatalogued when the copy is complete. I also wonder how they do it. Perhaps with the concurrent copy capability to somehow trap when a change is made to the source dataset? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Stupid ServerPac question
I've never been at the point where I do not have the physical device that I'll use to lay down 1.9. In the Modify System Layout, I want to have the target volumes be Mod 9's, which aren't ready yet (yeah tough to believe). I set the DYNAMIC DASD INFO to NO and then specified the device type and device address and VSN in the SUMP. All seems well but I get VOLS in the warning which indicates that it can't get to the VTOC. If I give it a real Mod 3, I get the over allocated message. Is there a way to go thru the Modify System Layout portion without having the real devices, which I thought NO to Dynamic would have done? TIA Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
I said this a few days ago. And maybe others are having problems with it as well. IF you are using FIREFOX (below V3) and you had clicked on IBM's [IBM Sign out] link that is at the top right of the pages (at least for me), their session cookies were NOT being correctly deleted. IF you are using FIREFOX V3 it appears that things are now handled correctly. The problems seen (before they put out a fix for the sign out process) were: * Bad cookies that caused you to be stuck on the signon page, * Getting some wild error message with a string of digits that was 200 characters (and saying something about this being a bad cookie). In certain cases, one needed to actually shutdown FIREFOX and restart it to get IBM's session cookies to actually go away. And even with that, one might also have to go manually delete cookies to get things corrected. There was also some indication that IE might have the problems if you are using IE in a tabbed mode rather than a stand alone instance per web application (I think that's what they were trying to say). And then, it took me calling a duty manager to get things going, because my SEV2 ticket was just not getting serviced. This gives me the impression that IBM does not take IBMLink seriously as they do other products they have that are mainframe (MVS) only. The discussions left me with the impression that the designers did not take into consideration that some people do not want to use IE, and that some users want to use tabbed mode which changes behaviors of the browser. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Knutson, Sam Sent: Wednesday, July 16, 2008 1:07 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO I have suggested IBM publish near real time and historical availability data for IBMLink. We do this internally (Web page known officially as Wall of Stability unofficially as Wall of Shame). The concept is users should have one very stable, simple place (no authentication public space) to go see current outages and past outages. If you are providing a highly available application this would be something to be proud of similar to 1527 SAFE WORK DAYS NO ACCIDENT at the factory entrance. So far this suggestion has not been met with enthusiasm. I want to see IBM build and monitor IBMLink with stock tools they sell to customers or Alpha/Beta releases in the process of going to RTM. If you are going to tell me how to build and monitor my applications you should eat your own dog food and show me how that works for you. Same goes for all the other vendors. IBMLink is a critical tool and one used by everyone here. IBM has smart, hard working people on this problem and they have spent considerable money to provide more redundant infrastructure and improve availability. They need to do better. We are crippled without IBMLink, ShopzSeries, and Resourcelink. I put in z/OS 1.9 on an LPAR this morning and we have been working several problems one of which I think we are about to open a PMR on. I don't like to think how the research to this point would have gone if I all I had was 1-800-IBM-SERV. I have seen several instances of HTTP 500 errors circumvented by existing all the browsers and starting a new one then logging back into IBMLink. I did call the help desk and was told this is fallout from yesterdays SEV1 ticket 36241384 and that 3 symptoms are being reported for a small percentage of users. HTTP 500 Server Error Entitlement page presented incorrectly Unable to process request In all the cases they know about exiting out of your browser and doing a new session with a signon has circumvented the problem. The ticket from yesterday is still open and they are still researching. Talking about IBMLink IMHO is fair game it is one of the most commonly used customer facing applications used by all system programmers for System z operating systems and subsystems. If it just worked no one would have reason to brutalize it. We talk about z/OS, SMPE, ServerPac, and IBMLink is just another tool. SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
- Original Message - From: Jeffrey Deaver [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 2:50 PM Subject: Re: Moving 3390-3 to 3390-9 It moves data sets while applications have them OPEN? Yes and No is my understanding.It moves the data so I/O is directed to the new location, but the move isn't committed until the ENQ is released. FDRMOVE, which we've used, works the same way. From the LDMF manual... 7. Completion phase Although the metadata has been modified, applications that were active before diversion will have their I/O redirected to the target location until they de-allocate the data set. For applications that continue to have the original source file allocation, a scheduled bounce will be required in order to free the original space Jeff, Thanks for the backup. Did I not say the applications had to be recycled for ENQ'd datasets? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
- Original Message - From: Edward Jaffe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 2:34 PM Subject: Re: Moving 3390-3 to 3390-9 Jousma, David wrote: Should have added that we have the product here, and it works well. Here is the link for info for non-believers... http://www-935.ibm.com/services/us/index.wss/offering/its/a1029927 Pretty slick! I was aware of the FDRPAS approach, which leverages the operating system's DDR SWAP logic. I was unaware that similar functionality could be had at the data set level. I wonder how they do it? And, if data can be moved while OPEN with data-set-level granularity, why use products that offer only volume-level granularity? Speed, plus the fact it's not really moved until the app is recycled (see Jeff Deaver's post). Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
Tom, I think we are arguing semantics here. The dataset is moved once LDMF completes, and new allocations of the moved datasets go to the new volume, and those tasks that had it allocated still get it at the old location until they are recycle, and LDMF takes care of keeping them in sync. What you said was: They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. When I read what you originally wrote, you seemed to imply that nothing could be done while the dataset was enqueued. Almost any dataset move is transparent if it is not allocated. :-) _ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, July 16, 2008 3:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving 3390-3 to 3390-9 - Original Message - From: Jeffrey Deaver [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 2:50 PM Subject: Re: Moving 3390-3 to 3390-9 It moves data sets while applications have them OPEN? Yes and No is my understanding.It moves the data so I/O is directed to the new location, but the move isn't committed until the ENQ is released. FDRMOVE, which we've used, works the same way. From the LDMF manual... 7. Completion phase Although the metadata has been modi-fied, applications that were active before diversion will have their I/O redirected to the target location until they de-allocate the data set. For applications that continue to have the original source file allocation, a scheduled bounce will be required in order to free the original space Jeff, Thanks for the backup. Did I not say the applications had to be recycled for ENQ'd datasets? Regards, Tom Conley This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IODF change causes next IPL to hang
Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf Rockwell Automation 414-382-4308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
On Wed, 16 Jul 2008 08:35:02 -0500, Rajeev [EMAIL PROTECTED] wrote: ... //FTPSTEP2 EXEC PGM=SORT,COND=(0,EQ,FTPSTEP1) //SORTLIB DD DSN=SORT.SORTLIB,DISP=SHR //SYSOUT DD SYSOUT=* //SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(7,2)) //SORTIN DD DSN=amp;amp;TEMPFILE, //DISP=(OLD,PASS) //SORTOUT DD DSN=amp;amp;STEP2FTP, //DISP=(NEW,PASS,DELETE), //SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA, //DCB=(RECFM=FB,LRECL=080,BLKSIZE=8000) //SYSINDD DSN=USR.PROCLIB.INPUT(FTPSORT),DISP=SHR //* //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //SYSPRINT DD SYSOUT=X //SYSOUT DD SYSOUT=X //INPUTDD * FTP.KAB.KLOUSRI.COM LMCOE lmc03 LOCSITE FWF1IENDLY CD /MAS PUT //DD:SORTOUT OUTPUT.FILE QUIT // ... Completely unrelated to the question being asked, but you might want to correct the spelling of FWFRIENDLY or just specify FWF. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stupid ServerPac question
Try telling ServerPac you need to initialize the volumes. On Wed, 16 Jul 2008 15:02:56 -0400, Jack Kelly [EMAIL PROTECTED] wrote: I've never been at the point where I do not have the physical device that I'll use to lay down 1.9. In the Modify System Layout, I want to have the target volumes be Mod 9's, which aren't ready yet (yeah tough to believe). I set the DYNAMIC DASD INFO to NO and then specified the device type and device address and VSN in the SUMP. All seems well but I get VOLS in the warning which indicates that it can't get to the VTOC. If I give it a real Mod 3, I get the over allocated message. Is there a way to go thru the Modify System Layout portion without having the real devices, which I thought NO to Dynamic would have done? TIA Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: ... This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. ... How long did you wait? Do you know it was not going to wake up? We have had some very long hangs in NIP lately, but it eventually would wake up. It felt like an eternity but I suspect it was 5-10 minutes of no obvious activity. Then the IPL process would take off and act like nothing had happened. No problems were noted afterwords. I don't think they were associated with IODF changes, did not effect all members of the PLex, and did not effect all LPARs on a single processor. In other words, we were never able to associate the hang with anything. We are on 1.8 and have both basic and parallel Sysplexes so our environments are quite different from yours (but I don't know how being part of a Sysplex could matter so early in the IPL.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stupid ServerPac question
Thank you Matthew. Specifying init=y, got me to msgCPP0605087W which seems to make the panel happy. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Do you have the compatibility PTF on z/OS 1.4 that will allow you to use the version 5 level IODF? The required maintenance is documented in the z/OS 1.7 Planning for Migration manual. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
- Original Message - From: Jousma, David [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 16, 2008 3:32 PM Subject: Re: Moving 3390-3 to 3390-9 Tom, I think we are arguing semantics here. The dataset is moved once LDMF completes, and new allocations of the moved datasets go to the new volume, and those tasks that had it allocated still get it at the old location until they are recycle, and LDMF takes care of keeping them in sync. What you said was: They're only transparent if the datasets are not ENQ'd. Any applications holding datasets will still have to be recycled so the dataset can move. When I read what you originally wrote, you seemed to imply that nothing could be done while the dataset was enqueued. Almost any dataset move is transparent if it is not allocated. :-) You say tomayto, I say tomahto... I was actually comparing the transparency of zDMF and FDRMOVE to FDRPAS and TDMF, which is completely transparent, even for ENQ'd datasets. Neither FDRMOVE nor zDMF provide the transparency of FDRPAS and TDMF, since you have to take an application outage to complete the move. Fair enough? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SDSF I (Input) Screen with z/OS 1.9
Hello, I migrated my first system to z/OS v1.9 this past weekend, and my Operations staff noticed that the SDSF I screen, and its column labeled POS appears to be broken. In looking at this same screen on a 1.8 system (in the same plex), the numbering sequence of jobs waiting appears correct (sequential). However, this same set of jobs on the 1.9 system has a POS numbering scheme that appears to be random, with position numbers missing. I did a quick search on IBMLink and IBM-Main, and found no hits. I also reviewed the 1.9 migration manual and found no reference to this SDSF screen. I am curisous if others who have migrated to z/OS 1.9 have encountered this, and if so, what has been your reaction. I have also opened a PMR with IBM. Thanks, Curt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
On Wed, 16 Jul 2008 15:32:27 -0400, Jousma, David [EMAIL PROTECTED] wrote: Tom, I think we are arguing semantics here. The dataset is moved once LDMF completes, and new allocations of the moved datasets go to the new volume, and those tasks that had it allocated still get it at the old location until they are recycle, and LDMF takes care of keeping them in sync. The old datasets are allocated, but the I/O is diverted to the new dataset. So the bounce is needed to free the old allocation, but if the system crashed for example, the new dsn is the good one (the 2 datasets are not kept in-sync after the diversion is complete). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. I've seen long delays when there are problems when the DASD goes into some sort of error recovery and retries each device for minutes before abandoning it and going to the next one. Alan ... This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. ... How long did you wait? Do you know it was not going to wake up? We have had some very long hangs in NIP lately, but it eventually would wake up. It felt like an eternity but I suspect it was 5-10 minutes of no obvious activity. Then the IPL process would take off and act like nothing had happened. No problems were noted afterwords. I don't think they were associated with IODF changes, did not effect all members of the PLex, and did not effect all LPARs on a single processor. In other words, we were never able to associate the hang with anything. We are on 1.8 and have both basic and parallel Sysplexes so our environments are quite different from yours (but I don't know how being part of a Sysplex could matter so early in the IPL.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
It's been a while since I've seen it because our current IODF maestro is on top of it, but our most common cause in the past of a long pause during NIP is failure to find an IODF that matches the hardware/HSA version. IOS (or whoever does the search) has a complicated and s-l-o-w procedure to search for an appropriate MVS linear cluster. If this is the problem, NIP will eventually settle on a usable IODF or it will wait state. It may take a while to reach either conclusion. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Stephen Wolf [EMAIL PROTECTED] LL.COMTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU IODF change causes next IPL to hang 07/16/2008 12:33 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF I (Input) Screen with z/OS 1.9
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Curt Thompson Hello, I migrated my first system to z/OS v1.9 this past weekend, and my Operations staff noticed that the SDSF I screen, and its column labeled POS appears to be broken. In looking at this same screen on a 1.8 system (in the same plex), the numbering sequence of jobs waiting appears correct (sequential). However, this same set of jobs on the 1.9 system has a POS numbering scheme that appears to be random, with position numbers missing. Different sort key, perhaps? At the moment I can't say whether we'd see something similar, because there are no jobs awaiting execution on either the 1.7 or 1.9 images. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF I (Input) Screen with z/OS 1.9
Have you re-assemed ISFPARMS, any exits, umods, etc with the correct macro levels? Have you removed module ISFLPA from LPALIB/LPALST? snip I migrated my first system to z/OS v1.9 this past weekend, and my Operations staff noticed that the SDSF I screen, and its column labeled POS appears to be broken. In looking at this same screen on a 1.8 system (in the same plex), the numbering sequence of jobs waiting appears correct (sequential). However, this same set of jobs on the 1.9 system has a POS numbering scheme that appears to be random, with position numbers missing. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
On Wed, 16 Jul 2008 16:28:10 -0400, Pinnacle [EMAIL PROTECTED] wrote: You say tomayto, I say tomahto... I was actually comparing the transparency of zDMF and FDRMOVE to FDRPAS and TDMF, which is completely transparent, even for ENQ'd datasets. Neither FDRMOVE nor zDMF provide the transparency of FDRPAS and TDMF, since you have to take an application outage to complete the move. Fair enough? Eventually... yes. Or close files, databases, etc. But that can also be considered an outage. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF I (Input) Screen with z/OS 1.9
On Wed, 16 Jul 2008 15:31:33 -0500, Curt Thompson [EMAIL PROTECTED] wrote: Hello, I migrated my first system to z/OS v1.9 this past weekend, and my Operations staff noticed that the SDSF I screen, and its column labeled POS appears to be broken. In looking at this same screen on a 1.8 system (in the same plex), the numbering sequence of jobs waiting appears correct (sequential). However, this same set of jobs on the 1.9 system has a POS numbering scheme that appears to be random, with position numbers missing. I did a quick search on IBMLink and IBM-Main, and found no hits. I also reviewed the 1.9 migration manual and found no reference to this SDSF screen. I am curisous if others who have migrated to z/OS 1.9 have encountered this, and if so, what has been your reaction. I have also opened a PMR with IBM. Nope. I did notice that dup jobs get a POS number under z/OS 1.9 and not on 1.8 from what I can tell. If you type ARRANGE ? in the command line is the POS width the same on both your 1.8 and 1.9 systems? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/16/2008 04:35:28 PM: Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. The documented way of invoking that function is IPLDATA STATUS Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
I've heard about a couple of things that can really slow an IPL down. One is an ESCON channel connected to nothing or a inop device. NIP (or somebody) will wait a very long time to see if it will come active. If there has been hardware microcode updates, the chp does not actually load the new microcode until a live LPAR tries to touch it. That can take a very long time. Worse if the chp is not connected to a live device. Try identifying dead or chp's and deactivate via the SE. Also expect long delays the first time a chp is used, even to an existing device. That scar is still fresh :-) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Wolf Sent: Wednesday, July 16, 2008 2:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IODF change causes next IPL to hang Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf Rockwell Automation 414-382-4308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 15:24:56 -0500, Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Do you have the compatibility PTF on z/OS 1.4 that will allow you to use the version 5 level IODF? The required maintenance is documented in the z/OS 1.7 Planning for Migration manual. Mark I just re-read what you wrote. Disregard what I wrote since you already had activated the V5 IODF on your 1.4 system. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
This is a very cool technique for debugging mysterious IPL slowdowns. You don't even need a dump - if you run this IPCS command on a running system, the IPLDATA STATUS command will tell you how long each module in the IPL process took to perform its function when that system was IPLed - even days later. Brian On Wed, 16 Jul 2008 16:54:29 -0400, Jim Mulder wrote: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/16/2008 04:35:28 PM: Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. The documented way of invoking that function is IPLDATA STATUS Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF I (Input) Screen with z/OS 1.9
There was a fundamental and as far as I know undocumented change in SDSF for 1.9. The change affected primarily the 'ST' and 'I' displays because of the mechanism used to collect information from JES2. We were an ESP customer for 1.9 and noticed early on that the 'I' and 'ST' displays were pretty much identical. In other words, 'I' displayed way more than it should have. That was fixed via APAR, but I can't find it at the moment. All users of SDSF at 1.9+ should look at OA25498 , which mentions the new Extended Status SSI interface. A number of anomalies are or might be attributable to this functional change. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Curt Thompson [EMAIL PROTECTED] INCIPAL.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU SDSF I (Input) Screen with z/OS 1.9 07/16/2008 01:31 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Hello, I migrated my first system to z/OS v1.9 this past weekend, and my Operations staff noticed that the SDSF I screen, and its column labeled POS appears to be broken. In looking at this same screen on a 1.8 system (in the same plex), the numbering sequence of jobs waiting appears correct (sequential). However, this same set of jobs on the 1.9 system has a POS numbering scheme that appears to be random, with position numbers missing. I did a quick search on IBMLink and IBM-Main, and found no hits. I also reviewed the 1.9 migration manual and found no reference to this SDSF screen. I am curisous if others who have migrated to z/OS 1.9 have encountered this, and if so, what has been your reaction. I have also opened a PMR with IBM. Thanks, Curt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Moving 3390-3 to 3390-9
This was not true with FDRPAS. I was able move even files for a CICS region without taking the region down. When I last used FDRPAS (6-7 years ago), we could move everything except page datasets. I think even that is resolved, now. But, don't take my word for it -- check the manual. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
I can't understand why some people think that IBM-Main is the place to talk about the status of IBMLink. Because it's one of the most important tools out there? And, we pay a lot of money for it? We b*tch and moan about other lousy services and software for the mainframe, so why not the support tools? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HSM recall on one LPAR for request on another lpar
I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM recall on one LPAR for request on another lpar
I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. What is the risk? Are they in the same SYSPLEX? So occasionally during testing on LPAR:TEST I have to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around this? That process is always going to cause the error. My suggestion (done in the past) is to put up an HSM on the test LPAR, but not let it do any archiving/back-up; just recalls. Otherwise, continue with what you're doing. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO/ISPF Screen Swap
I'm late in thanking everyone for replying to my question. Thanks for refreshing an old brain. Regards. --- On Mon, 7/14/08, Gary Green [EMAIL PROTECTED] wrote: From: Gary Green [EMAIL PROTECTED] Subject: Re: TSO/ISPF Screen Swap To: IBM-MAIN@BAMA.UA.EDU Date: Monday, July 14, 2008, 9:35 AM What you're thinking of is SWAP NEXT or SWAP PREV. Next goes to the next ISPF screen in the list. Prev does the reverse (it goes backwards). If it matters, I have ALL my swap related keys coded as PF2 SPLIT NEW PF9 SWAP NEXT PF14 SPLIT LIST PF21 SWAP PREV And since I usually control the system I change the ISPF CONFIG to allow 32 split screens. And, usually, I am the only one that takes advantage of this capability (multiple, i.e. more than 2, split screens). Works like a charm! On Mon Jul 14 5:11 , Howard Rifkind [EMAIL PROTECTED] sent: I used to have the PF keys on my PC set put to swap between different screens but I'm no longer in possession of that PC and I can't recall how I did this. I'm opening up several screens with the start command and I would like to know how to switch between them. If I open up three screens and use the swap command I seem to only be able to switch between two of them. Also, how do I go about seeing which screen are available, I used to see this also with a PF key setting and then select the one I wanted. Thanks... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Example of what a very small JCL Interpreter can do to your installation.
There has been some talk about changing JCL interpretation. Sure it is old, and ugly, but we are used to it, and it does work. Here is what happened going from os390 to zos 1.08 Somewhere between OS390 2.10 (our old system) and zos 1.08 (our new system) the JCL interpreter changed. Here is a simplified example of some JCL we have been running for years. //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* WHEREEVER /* Note the Extra sysin which the programmer left there in case he ever needed it again, soft of self documenting. Worked just fine... until zOS 1.08 Here is how OS390 2.10 handles the GENERATED SYSIN //JS001 EXEC PROC=UNVTEST ++UNVTEST PROC ++PS001 EXEC PGM=IEFBR14 ++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE ++SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD * +/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB ++SYSPRINT DD SYSOUT=* //SYSIN DD * GENERATED STATEMENT Here is how zOS 1.08 handles the GENERATED SYSIN 4 ++UNVTEST PROC 5 ++PS001 EXEC PGM=IEFBR14 6 ++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE 7 //SYSIN DD * GENERATED STATEMENT +/SYSINDD DISP=SHR,DSN=QALC.UNVLIB 8 //MYSCRIPT DD * +/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB 9 ++SYSPRINT DD SYSOUT=* The os390 way, the JCL works. zOS 1.8 it gets the old WHEREVER junk in the sysin dd and fails. Sigh. Notice that zos 1.08 neatly lines up the sysin from way down at the bottom with the existing SYSIN. Perfect example of a program being TOO HELPFUL. It wasn't broke, why did you fix it. So, is this a bug or working as designed? Or maybe there is an option somewhere that I can change and have it work the way it used to. MUCH better than changing hundreds of pieces of JCL. Really. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HSM recall on one LPAR for request on another lpar
No sysplex, Each is a MONOPLEX, and GRS ring is active, all DASD shared. Anyone see any possible downside to having the sandbox lpar do RECALL's only? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
These days it's called CA-Spool. See? I said I'm not a printer person! :-) (I have no clue how to *access* that thing, either!) Did the 'missing' output ever really exist? Perhaps the application opened the file but never actually wrote anything. I guess I didn't make it very clear that my colleague submitted the *same* job about 20 times *at the same time* to test. He even used the same jobname for it. Sometimes the systsprt made it into ESF, in 3 of 20 cases it did not, but sometimes all 20 cases arrived correctly. In and of itself, the job works, you can see the output (some status display for some network resource) in SDSF. What are the (default) characteristics of SYSOUT CLASS H? Anything special, or different than whatever the MSGCLASS of the JOB is? $HASP842 OUTCLASS(H) OUTPUT=PRINT,BLNKTRNC=YES, $HASP842 OUTDISP=(WRITE,WRITE),TRKCELL=YES The default class (X) had outdisp=(hold,hold). My colleague has changed the default class for his testing to Z (the big waste paper basket): HASP842 OUTCLASS(Z) OUTPUT=DUMMY,BLNKTRNC=YES, HASP842 OUTDISP=(WRITE,WRITE),TRKCELL=NO It occured with both X and Z, but in no way predictably. Is the output that does NOT disappear also SPOOLed to SYSOUT CLASS H? Is that (non-disappearing) output also DESTed to R720? Not sure I understand the question. He told me that he *saw* the output via SDSF (I assume that means it was spooled in JES), but it never made it to ESF. It was just purged from the spool. The output that made it into ESF was later purged (presumably because ESF set the purge bit). From what little I know about this, ESF will do the printing to R720 if instructed to do so. So far the only thing common to all the disappearing output (that we could see) was that it was purged from another system than all the others. I had hoped to avoid looking at SMF records, because the jobnames are all the same, and I will have to look at about 200 of those same jobs. Guess it's time to get out a little SAS program. What worries me is that this started happening after a maintenance refresh to this sysplex (1.8). In the past, we have had cases where the purge bit was mysteriously set for a TSO user (we never found out why or how, and IBM was also only shrugging their collective shoulders), which resulted in that TSO user not being able to xmit/receive anything anymore (that's how we found that out). Unfortunately, by the time we know which output is missing we cannot check the status of the output anymore because it is already gone. :-( I'll let y'all know if we find anything. Best regards, Barbara -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
In a message dated 7/17/2008 12:12:28 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: look at about 200 of those same jobs. Guess it's time to get out a little SAS program. IIRC you said you had ITRM. There's a member ANALPRT in SOURCLIB that's pretty good although don't know how to see missing stuff. Maybe no PURGED record gets cut? **Get the scoop on last night's hottest shows and the live music scene in your area - Check out TourTracker.com! (http://www.tourtracker.com?NCID=aolmus0005000112) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
