Re: Question About DFDSS :FCNOCOPY/FCWITHDRAW
Esmie, I would add the UTILMSG=YES parameter to the backup EXEC statements. This will tell you if DFSMSdss is invoking ICKDSF to init the volumes instead of simply issuing the FCWITHDRAW after the DUMP is completed. If ICKDSF is being invoked, it is because the VTOC tracks of the DASD volume are in a target FlashCopy relationship, and issuing an FCWITHDRAW against them could well cause the volume to be online but invalid (because the VTOC location now contains the residual data from before the FlashCopy was done to it). Thanks, Andrew Wilt IBM DFSMSdss Architecture/Development IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/08/2008 08:43:05 AM: [image removed] Question About DFDSS :FCNOCOPY/FCWITHDRAW esmie moo to: IBM-MAIN 05/08/2008 08:46 AM Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Good Morning Gentle Readers, I am investigating a problem with a backup(backups of SNAP volumes) that is executed daily. For some reason in the last 2 days the backup has been taking 12-15 hours to execute. I covered all angles : changes to the job, Z/OS version, tape mounts/tape drives, scheduling, envirnonment changes etc. Nothing has been changed. I /snip //BACKUP1 EXEC PGM=ADRDSSU,TIME=60 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //DEV1LST DD SYSOUT=* //INDEVDD UNIT=3390,VOL=SER=SNAP01,DISP=SHR //OUTDEV DD DSN=SYS2.BACKUP1.OUT.SYS001(+1), //DISP=(,CATLG,DELETE), //DCB=GDGDSCB, //UNIT=3490,VOL=(,RETAIN), //LABEL=(01,SL) //SYSINDD * DUMP FULL INDD(INDEV) OUTDD(OUTDEV) CAN OPT(4) FCWITHDRAW //* //BACKUP2 EXEC PGM=ADRDSSU,TIME=60 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //DEV1LST DD SYSOUT=* /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
Server Pac Download Errors
This is the first time I have used FTP to download a Serverpac. I have read the documentation but restart processes seem a little light. After running for close to 10 hours my job to retrieve the Serverpac from the IBM server failed with the following messages GIM44500IVERIFICATION OF HASH VALUE OF FILE S0895.CPPUNLD.OS191348.SMPE.SMPPTS.pax.Z FAILED. SMP/E WILL RETRY RETRIEVAL OF THE FILE. GIM43500S ** THE CALL TO THE BPX1WRT SERVICE FAILED. THE RETURN CODE WAS '008C'X AND THE REASON CODE WAS '059D0129'X. GIM43500S ** THE CALL TO THE BPX1WRT SERVICE FAILED. THE RETURN CODE WAS '008C'X AND THE REASON CODE WAS '059D0129'X. GIM46200S ** GIMGTPKG PROCESSING HAS FAILED BECAUSE THERE WAS AN FTP ERROR. GIM47601IPACKAGE OS191348.content WAS PARTIALLY STAGED TO THE SMPNTS. GIM20501IGIMGTPKG PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Connection to server interrupted or timed out. Receiving data SC3656 receive_data: recv() failed - EDC5120I Interrupted function call. (errno2 =0x76650291) recv error from receive_data - EDC5120I Interrupted function call. (errno2=0x766 50291) SC2331 dataClose: entered Connection with dispsd-76.boulder.ibm.com terminated CZ1215 ftpClose: entered TI2456 wrt_image_notds: receive error = -2 MF0662 seq_close_file: file closed CG1920 hfs_rcvFile: receive error (-2) Transfer aborted due to receive error (-2) SC2331 dataClose: entered CU2258 write_smf_record: entered with type 16. CU1691 write_smf_record_119: entered with type 16. CU2535 write_smf_record: length of smfrecord: 305 CG3750 rcvFile: rc -1 rc_write -2 rc_close 0 CX0348 main: RC=-0001 cmd_in_progress=16 CX0351 main: last_reply= 150 err=10 PC0904 setClientRC: entered PC0974 setClientRC: std_rc=16150, rc_type=STD, rc=16150 Std Return Code = 16150, Error Code = 00010 CZ1143 ftpQuit: entered CZ1215 ftpClose: entered CZ1215 ftpClose: entered CX0482 removeAff: entered I went ahead and restarted as per the JCL instructions from the COPYHASH step. What I am not clear on Did I need to delete the failed file? The S0895.CPPUNLD.OS191348.SMPE.SMPPTS.pax.Z? Or will this process clean it up itself? I have noticed that the restarted job is not download those files already successfully downloaded to my HFS. I am just curious about these errors and what they are telling me. Thanks. Lizette -- 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: Server Pac Download Errors
On Sat, 10 May 2008 08:42:36 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: This is the first time I have used FTP to download a Serverpac. I have read the documentation but restart processes seem a little light. After running for close to 10 hours my job to retrieve the Serverpac from the IBM server failed with the following messages GIM44500IVERIFICATION OF HASH VALUE OF FILE S0895.CPPUNLD.OS191348.SMPE.SMPPTS.pax.Z FAILED. SMP/E WILL RETRY RETRIEVAL OF THE FILE. GIM43500S ** THE CALL TO THE BPX1WRT SERVICE FAILED. THE RETURN CODE WAS '008C'X AND THE REASON CODE WAS '059D0129'X. Was there more information in SYSPRINT? GIM43500S ** THE CALL TO THE BPX1WRT SERVICE FAILED. THE RETURN CODE WAS '008C'X AND THE REASON CODE WAS '059D0129'X. GIM46200S ** GIMGTPKG PROCESSING HAS FAILED BECAUSE THERE WAS AN FTP ERROR. GIM47601IPACKAGE OS191348.content WAS PARTIALLY STAGED TO THE SMPNTS. GIM20501IGIMGTPKG PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Connection to server interrupted or timed out. Receiving data Did I need to delete the failed file? The S0895.CPPUNLD.OS191348.SMPE.SMPPTS.pax.Z? Or will this process clean it up From: Title: SMP/E V3R4.0 Commands Document Number: SA22-7771-11 14.4.3 Restarting RECEIVE FROMNETWORK If errors occur during the transfer of files for a package, it may be necessary to restart the RECEIVE FROMNETWORK operation in order to complete the transfer of the entire package. You can simply rerun the RECEIVE FROMNETWORK command, and SMP/E will determine which files have already been transferred successfully, and which files need to be transferred again or have not yet been transferred. Before transferring a file, RECEIVE processing checks to see if the file already exists in the package directory of the SMPNTS. If it does, the hash value for the existing file is calculated and compared to the hash value supplied in the package attribute file. If they match, the file is used as it exists in the package directory and is not transferred again. If the hash value of the existing file does not match the value supplied in the package attribute file, the file is transferred from the FTP server and replaces the existing file in the package directory. I believe RECEIVE FROMNETWORK is the underlying service and all the above should apply. -- gil -- 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: Server Pac Download Errors
Thanks for the response, I just did not realize that this type of job would take close to 10 hours to pull the serverpac from the IBM server and that there might be time outs causing resubmissions. I was hoping for one continuous job run. I also learned that my 10,000 cy HFS file I am using for this download from IBM to my HFS file took 95% of this file. I guess I am going to beg my Storage guys to get me 1 or 2 MOD-27 volumes for this process. Lizette -- 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: How to cancel with just the JES jobid?
SSI function code 54 can be used to retrieve the JES command character. It will also tell you if you are running under JES2 or JES3, the version level, and lots more information. Title: z/OS V1R9.0 MVS Using the Subsystem Interface Document Number: SA22-7642-06 Has the details, and even has a sample program to extract the data. Note that the z/OS 1.9 level of the manual does not show the COMMAND_PREFIX= value, which may imply that it is not yet available for JES3 sites. It has been available in JES2 since z/OS 1.5. /jack - Original Message - From: Mark Jones [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, May 09, 2008 3:34 PM Subject: How to cancel with just the JES jobid? snip JES Cancel JES2 and JES3 have completely different syntax for cancel, so I have to know which type I'm talking to. The CVT points to the JESCT (the main JES controlblock) which has a flag to test for JES2/JES3. That's not too hard. However, the JES2/JES3 commands are normally prefixed with $ (JES2) or * (JES3), but that is really just the subsystem command prefix and could be anything. I can't find the subsystem command character. It isn't in the JESCT or any obvious place. Any notion where that might be kept? Maybe it can be gotten through a subsystem interface call? Without knowing what command character is used for the primary JES, I can just default to $ for JES2 and * for JES3, but if a customer has changed that from the norm, it won't work. Any help on these issues or other approaches for cancelling jobs would be much appreciated. - Mark -- 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: How to cancel with just the JES jobid?
Jack Schudel wrote: Note that the z/OS 1.9 level of the manual does not show the COMMAND_PREFIX= value, which may imply that it is not yet available for JES3 sites. It has been available in JES2 since z/OS 1.5. I doubt IBM JES3 would ever populate this field to make it compatible with JES2. JES2 command prefixes are always system-scoped. JES3 is sysplex aware and allows up to seven sysplex-scoped prefixes and up to seven system-scoped prefixes. Even if they chose to report those prefixes via COMMAND_PREFIX= in SSI 54, the format would have to be substantially different. -- 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: Server Pac Download Errors
Hi Lizette, Like any other IP process, speed is determined by a number of things, bandwidth, sever load, number of hops, etc. I pulled down 2 years worth of maint for a 1.4 system a couple of years or so and it took a liitle over 17 hours and broke on timeouts a bunch of times. I just followed the directions in the JCL each time I restarted and it finally finished. I was fine. When I brought my 1.8 ServerPac home it only took 11 hours and only broke on time outs a couple of times. Linda -- Original message -- From: Lizette Koehler [EMAIL PROTECTED] Thanks for the response, I just did not realize that this type of job would take close to 10 hours to pull the serverpac from the IBM server and that there might be time outs causing resubmissions. I was hoping for one continuous job run. I also learned that my 10,000 cy HFS file I am using for this download from IBM to my HFS file took 95% of this file. I guess I am going to beg my Storage guys to get me 1 or 2 MOD-27 volumes for this process. Lizette -- 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: How to cancel with just the JES jobid?
Going back to the OP's question about finding the current installation's command character to allow him to issue a JES cancel by jobid command, would it be sufficient in a JES3 environment to just extract any of the JES3 command characters from a D OPDATA console command, since JES3 sites do not have to worry about running under poly-JES? Thanks, -jack - Original Message - From: Edward Jaffe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Saturday, May 10, 2008 1:24 PM Subject: Re: How to cancel with just the JES jobid? Jack Schudel wrote: Note that the z/OS 1.9 level of the manual does not show the COMMAND_PREFIX= value, which may imply that it is not yet available for JES3 sites. It has been available in JES2 since z/OS 1.5. I doubt IBM JES3 would ever populate this field to make it compatible with JES2. JES2 command prefixes are always system-scoped. JES3 is sysplex aware and allows up to seven sysplex-scoped prefixes and up to seven system-scoped prefixes. Even if they chose to report those prefixes via COMMAND_PREFIX= in SSI 54, the format would have to be substantially different. -- 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: How to allocate multiple uncataloged datasets?
On Fri, 9 May 2008 16:02:56 -0500, Ron MacRae [EMAIL PROTECTED] wrote:
Ladies and gents,
If I want to ALLOCATE an uncataloged dataset in a rexx exec I can issue -
alloc dataset('DSN1') file(MYDD) volume(VOL1) shr.
How do I ALLOCATE multiple uncataloged datasets?
alloc dataset('DSN1' 'DSN2') file(MYDD) volume(VOL1 VOL2) shr
doesn't work.
If I allocate either file individually I get the correct, uncataloged, files
allocated.
If I allocate both together I get the cataloged versions.
What am I doing wrong?
How do you allocate multiple uncataloged versions of datasets?
You can use BPXWDYN or one of the CONCAT commands floating around.
This has been discussed several times recently. Search the archives.
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: IFAQUAA layout for IFAQUERY
At 18:14 -0400 on 05/08/2008, Rob Scott wrote about Re: IFAQUAA layout for IFAQUERY: Roland How about using IFAQUAA QUAHDR=NO The format of the header blocks is the same (although the name of the offset to the first record field is different- tsk tsk) An option available to IBM is to map the QUAHDR DSECT in an independent macro and then just invoke it from within xxxQUAA... Another solution since the mappings and names (except for that one case) are the same is to have a global set symbol to say that the section was already expanded and bypass the 2nd expansion. Also define the offset to the first record field with both labels. I'm assuming that the DSECT is a separate DSECT which uses a separate USING not one that uses the base USING of the Macro and just jumps over this section in the definitions. -- 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: Server Pac Download Errors
Linda, Thanks for your response, that makes more sense now. I thought perhaps I was doing something incorrectly. But since you have a similar experience, I will just add to my notes for the future that this is just one of those time consuming processes that will probably get time outs. Now, all I have to worry about is space for the receiving HFS. :-D Lizette [] -- Snip Like any other IP process, speed is determined by a number of things, bandwidth, sever load, number of hops, etc. I pulled down 2 years worth of maint for a 1.4 system a couple of years or so and it took a liitle over 17 hours and broke on timeouts a bunch of times. I just followed the directions in the JCL each time I restarted and it finally finished. I was fine. When I brought my 1.8 ServerPac home it only took 11 hours and only broke on time outs a couple of times. [] -- UnSnip -- 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: How to cancel with just the JES jobid?
Jack Schudel wrote: Going back to the OP's question about finding the current installation's command character to allow him to issue a JES cancel by jobid command, would it be sufficient in a JES3 environment to just extract any of the JES3 command characters from a D OPDATA console command, since JES3 sites do not have to worry about running under poly-JES? Having to capture output from D OPDATA is lame. (CPF should have a QUERY function to allow inspection of existing prefixes!) Having to issue JES-specific operator commands is even more lame. IMHO, nothing beats SSI 2 for the OP's stated purpose. -- 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: How to cancel with just the JES jobid?
Ed, I agree, the SSI manual is (almost) useless. I was in the process of writing a NOTIFY like process at my third employer before it was brought to my attention that the SSI was now documented, I think I wrote the first one in 1990 or something like it. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, May 10, 2008 12:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How to cancel with just the JES jobid? Mark Jones wrote: On Fri, 9 May 2008 13:06:08 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Are you able to use SSI function code 2 (CANCEL)? IEFSSCS has the SSOB mapping. Yes I guess, but it isn't documented in the MVS Using the Subsystem Interface manual. I could try to figure it out based on similar SSI calls, but would rather use a documented interface. I'll check into the SSOB mapping and see if I can figure it out. Thanks for the idea. I never really noticed, until you mentioned it, that SSI function code 2 (CANCEL) wasn't documented. In fact, I now see lots of ordinary, every-day SSI calls aren't in Using the SSI. That's ridiculous. Perhaps the authors of the book weren't particularly proud of the interfaces they neglected to mention. (A lot of it is pretty gross.) Or maybe they only had so much time money to devote. Or maybe they were just lazy. In the old days, there was no book. The SSI documentation was the JES source code. And, for me it still is... -- 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: Server Pac Download Errors
Hi Lizette, I found that I also needed unpacking room, the SMPWKDIR, also a HFS file, at minimum the same size as the SMPNTS, but better to allow more. If you need multi-volume it will have to be SMS controlled. I have only 3390 mod 3 images, so I made each extent equal to 1/3 of the pack and I had 4 packs for the 1.7 ServerPac SMPWKDIR. I don't have a whole lot of products in there either, no DB2, no CICS, no WebSphere. If you check the extents every once in a while you could add another volume to the pool while it's running. Did that while I was at work, but left it to run overnight. When it broke on space, just followed the directions and restarted. I did not need to start over, just restart. Just a thought, if you don't do this already - I assign my SMPPTS to a volume (mine are all mod3) all by itself. That way as it grows it can stay on the same volume and I don't have to bother defining spill datasets and I don't have to wait for compresses to run very often. I know that PTFs can be deleted, but it is very convenient to look in the SMPPTS at the fix rather have having to look online. Linda -- Original message -- From: Lizette Koehler [EMAIL PROTECTED] Linda, Thanks for your response, that makes more sense now. I thought perhaps I was doing something incorrectly. But since you have a similar experience, I will just add to my notes for the future that this is just one of those time consuming processes that will probably get time outs. Now, all I have to worry about is space for the receiving HFS. :-D Lizette [] -- Snip Like any other IP process, speed is determined by a number of things, bandwidth, sever load, number of hops, etc. I pulled down 2 years worth of maint for a 1.4 system a couple of years or so and it took a liitle over 17 hours and broke on timeouts a bunch of times. I just followed the directions in the JCL each time I restarted and it finally finished. I was fine. When I brought my 1.8 ServerPac home it only took 11 hours and only broke on time outs a couple of times. [] -- UnSnip -- 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
