Re: IOCDS - Default Profile
W dniu 2013-01-25 05:34, Jake anderson pisze: Dear All, I know this could be a very basic or repetitive question, but I am unable to find any Clue. Here We are playing around with our Z800 machine(Now used only for Testing Purpose), We are adding another LPAR to the IODF. So the currently the scenario is our Reset Profile is "DFLTEST". Now we want make another Profile "MTLTEST" as the Default reset profile, so that it invokes the newly added Image. Could someone please guide me the way to modify "MTLTEST" as the Default Reset profile ? Any direction or suggestion would be really great. Assign button. The profile should be "Assinged for activation". Open profile list, choose the profile, select Customize. BTW: Another Reset profile is tricky. You want to have DFLTEST with - let's say 3 LPARs and MTLTEST with those 3 LPARs + another one. Assuming your 3 LPARs consume all available memory, in order to activate fourth LPAR you need to change memory assignments. THE CHANGE WILL AFFECT DLFTEST ALSO! Reason: LPAR settings are recorded in LPAR profile and there is only one LPAR profile per LPAR name. So THE SAME LPAR profile will be used in DLFTEST and MTLTEST. Workaround: MTLTEST should use completely new names for all 4 LPARs. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
Kees Vernooij kindly wrote: >>Yup. About windoze, try removing your USB stick while something is writing on >>it. Safety of contents on that stick is NOT guaranteed. Or do a CD/DVD >eject >>while doing a pirate copy of something... BTDT. ;-D >If you compare, compare equal situations: I don't think z/OS will do better if >you pull out the only channel to a device it is writing to... Agreed. I always wanted to see one doing that stunt [1], just to see what z/OS will do [MIH and abends for example], or more specifically, what will that drive's controller and its cache will do with those orphaned blocks. Groete / Greetings Elardus Engelbrecht [1] - One of our operator pushed by accident a trolley full of 3480 cartridges over some ESCON optic cables. It was while we were installing ESCON and getting those copper wires out. Some of thes cables were 'live' and others were waiting to be connected. Luckily only those cables waiting to be connected, were damaged, while the 'live' ones were very dangerously lied nearby!! We had to fly in new cables while the op was 'enjoying' the 'Red Carpet' before the top brass... Ouch-ouch-ouch... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
Thanks to all who replied, I know now what to use as search args, so I retried my searches on my favourite toy. This is what I found in a very ancient proclib (Recalled=browsed=migrated - hard work just to see one stupid line :-D) BROWSE.PROCLIB.backup(X) Command ===> //S1 EXEC PGM=IEFBR14 My operators are indeed just as lazy like my users with their passwords. minimum hand movements... ;-) As shipped by that big blue one (z/OS v1.12): BROWSE..PROCLIB(DEALLOC) Command ===> * Top of Data * //DEALLOC EXEC PGM=IEFBR14 //DUMMY1 DD DUMMY //* THIS PROCEDURE IS ACTIVATED BY A 'START DEALLOC' COMMAND TO //* EXECUTE IEFBR14 CAUSING ALLOCATION TO DEALLOCATE A //* DEVICE SPECIFIED ON A PREVIOUS 'VARY OFFLINE' COMMAND. Thanks again to all, my curiousity has been cured. ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
I think this issue was that allocation needed to be driven. With TSO active on the system it was almost never an issue but I think in MSS days there was an issue of demounting the MSS volumes (we got LONG Q4 backup ups) they (IBM) rewrote parts of alloc/dealloc because of MSS and if I recall correctly because of our issues (many IPL's) so what was happening then is not equilivent now days. Ed On Jan 24, 2013, at 8:51 AM, Alan Field wrote: I seem to recall a S DEALLOC command issued from the console (console being a modified SELECTRIC typewriter) and //DEALLOC PROC //S1 EXEC PGM=IEFBR14 Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 From: "Elardus Engelbrecht" To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/24/2013 08:42 Subject:Re: Varying off path while it is in use Sent by:IBM Mainframe Discussion List m...@listserv.ua.edu> Paul Gilmartin wrote: Remember the Bad Old Days when the operator needed to submit a dummy job to make a device actually go offline? (Or does it still work that way?) Geez, your memory is better than my decaying memory! Can you e-mail some [unused?] braincells to me? ;-D I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion years ago that I see that dummy job. I have searched NOW my RACF DB, procs, etc. Nothing there... Question: what was the PGM and parms used in that dummy job? Just curious of course! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this communication may be confidential, and is intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. Unencrypted, unauthenticated Internet e-mail is inherently insecure. Internet messages may be corrupted or incomplete, or may incorrectly identify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IOCDS - Default Profile
Dear All, I know this could be a very basic or repetitive question, but I am unable to find any Clue. Here We are playing around with our Z800 machine(Now used only for Testing Purpose), We are adding another LPAR to the IODF. So the currently the scenario is our Reset Profile is "DFLTEST". Now we want make another Profile "MTLTEST" as the Default reset profile, so that it invokes the newly added Image. Could someone please guide me the way to modify "MTLTEST" as the Default Reset profile ? Any direction or suggestion would be really great. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
At 15:20 -0600 on 01/24/2013, Joel C. Ewing wrote about Re: DIFFERENTIATION OF VSAM DSNS: I've never considered trying to recover KSDS records from just the DATA component from a physical volume dump, but if this was a KSDS with INDEX on a different volume that could be the case you face. If it can be done by faking it as an ESDS, at best you could only recover the data records in physical CI order, not key order, as any CI splits and CA splits in the original KSDS would render the logical ordering of the CI's unknown without the corresponding INDEX CI's. JC Ewing Try allocating a new KSDS and doing a copy of the recovered DATA component (faked as an ESDS) into it. This will recreate the INDEX on the fly as you read the records (even though they are out of order) since you are adding the records to the KSDS not creating it from a sorted file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
If it is a physical dump, is there a way to search for matching VTOC entries on the tape? Or could a SPHERE keyword get all associated VSAM files? On Thu, Jan 24, 2013 at 3:20 PM, Joel C. Ewing wrote: > If the original problem was that the dataset was inadvertently deleted, then > you would have lost the catalog and VVDS entries as well. But if you know > the approximate time of deletion and have SMF records from that period, you > could use freeware DAF (Dataset Audit Facility) from Michael Cleary > https://sites.google.com/site/michaeljosephcleary/home/freeware > to scan SMF records and see if an INDEX component was deleted at the same > time and what volume(s) it was on. > > If all you have is a physical volume DUMP as stated, dss TYPRUN=NORUN would > probably be unable to provide any CLUSTER association info, and the INDEX > component might be on another volume and not even in the same dump. Short > of lfinding both DATA and INDEX components in the same dump, recognizing you > had a KSDS would be difficult without either the old catalog entry or the > original IDCAMS DEFINE statement. > > One requirement we had was that every production (and test counterpart) VSAM > dataset had to have a corresponding member in a "known" PDS that gave the > IDCAMS statements for redefining the data set (and any alternate indices), > so that in-house utilities could reorganize the file if necessary, or so you > would at least have some place to start in event of dataset loss and there > would be no question about the data set attributes. > > I've never considered trying to recover KSDS records from just the DATA > component from a physical volume dump, but if this was a KSDS with INDEX on > a different volume that could be the case you face. If it can be done by > faking it as an ESDS, at best you could only recover the data records in > physical CI order, not key order, as any CI splits and CA splits in the > original KSDS would render the logical ordering of the CI's unknown without > the corresponding INDEX CI's. > JC Ewing > > On 01/24/2013 12:39 PM, willie bunter wrote: >> >> Boris, >> Thanks for the valuable information. One last question. With the >> problem I encountered, since the dataset was restored from a physical DFDSS >> backup, only the DATA component was restored. I tried the LISTCAT of the >> .DATA component and since there was no cluster the LISTCAT was unsuccessful. >> In this case, how would I be able to tell what type of VSAM dsn it is? >> >> >> >> From: Boris Lenz >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Thursday, January 24, 2013 1:00:54 PM >> Subject: Re: DIFFERENTIATION OF VSAM DSNS >> >> >> On Thu, January 24, 2013 18:25, willie bunter wrote: >>> >>> I checked the LISTCAT however I didn't see anything. Any suggestions? >> >> Examine the output of LISTCAT ENT(/) ALL. >> >> KSDS: >> - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. >> - has an INDEXED ATTRIBUTE in the DATA section. >> >> VRRDS: >> - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. >> - has a NUMBERED ATTRIBUTE in the DATA section. >> >> ESDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a NONINDEXED ATTRIBUTE in the DATA section. >> >> LDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a LINEAR ATTRIBUTE in the DATA section. >> >> RRDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a NUMBERED ATTRIBUTE in the DATA section. >> >> Regards, >> Boris >> >> > ... > > -- > Joel C. Ewing,Bentonville, AR jcew...@acm.org > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
If the original problem was that the dataset was inadvertently deleted, then you would have lost the catalog and VVDS entries as well. But if you know the approximate time of deletion and have SMF records from that period, you could use freeware DAF (Dataset Audit Facility) from Michael Cleary https://sites.google.com/site/michaeljosephcleary/home/freeware to scan SMF records and see if an INDEX component was deleted at the same time and what volume(s) it was on. If all you have is a physical volume DUMP as stated, dss TYPRUN=NORUN would probably be unable to provide any CLUSTER association info, and the INDEX component might be on another volume and not even in the same dump. Short of lfinding both DATA and INDEX components in the same dump, recognizing you had a KSDS would be difficult without either the old catalog entry or the original IDCAMS DEFINE statement. One requirement we had was that every production (and test counterpart) VSAM dataset had to have a corresponding member in a "known" PDS that gave the IDCAMS statements for redefining the data set (and any alternate indices), so that in-house utilities could reorganize the file if necessary, or so you would at least have some place to start in event of dataset loss and there would be no question about the data set attributes. I've never considered trying to recover KSDS records from just the DATA component from a physical volume dump, but if this was a KSDS with INDEX on a different volume that could be the case you face. If it can be done by faking it as an ESDS, at best you could only recover the data records in physical CI order, not key order, as any CI splits and CA splits in the original KSDS would render the logical ordering of the CI's unknown without the corresponding INDEX CI's. JC Ewing On 01/24/2013 12:39 PM, willie bunter wrote: Boris, Thanks for the valuable information. One last question. With the problem I encountered, since the dataset was restored from a physical DFDSS backup, only the DATA component was restored. I tried the LISTCAT of the .DATA component and since there was no cluster the LISTCAT was unsuccessful. In this case, how would I be able to tell what type of VSAM dsn it is? From: Boris Lenz To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, January 24, 2013 1:00:54 PM Subject: Re: DIFFERENTIATION OF VSAM DSNS On Thu, January 24, 2013 18:25, willie bunter wrote: I checked the LISTCAT however I didn't see anything. Any suggestions? Examine the output of LISTCAT ENT(/) ALL. KSDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has an INDEXED ATTRIBUTE in the DATA section. VRRDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. ESDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NONINDEXED ATTRIBUTE in the DATA section. LDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a LINEAR ATTRIBUTE in the DATA section. RRDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. Regards, Boris ... -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On 2013-01-24 13:06, Bill Fairchild wrote: > I remember using "S X" a long time ago myself. There was no proclib member > named X, the member would not be found, but allocation was driven away so the > device went offline. This all worked fine until someone put a real member > into SYS1.PROCLIB named "X" to do something special, not knowing what the > operators were doing. Then surprising results happened. It's better to used > the official method, namely "S DEALLOC". > Or create an alias? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
Yeah, I found it easier in the long run to Restore with Rename and figure it out from there. Hardest one I ever saw was a multi-volume with 5 AIXes spread all over the place. In a message dated 1/24/2013 2:57:26 P.M. Central Standard Time, darth.kel...@assurant.com writes: I could match up the day the backup was created against that day's DCOLLECT & pull the information there. There are other ways & tools you can use to collect historical data. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
Another option I have available to me is we run a daily DCOLLECT against all the volumes. I could match up the day the backup was created against that day's DCOLLECT & pull the information there. There are other ways & tools you can use to collect historical data. ddk - So maybe I'm totally off-base here, but it seems to me like the original request is that he wanted to know from the tape what kind of VSAM files were on the backup. I ran with my Restore with PARM='TYPERUN=NORUN' and got this from the output. Granted it's not fool proof. You can pick out the KSDS, the other 2 happen to be SMS datasets, so I know that they are LDS's - but as to RRDS, ESDS, etc Hope that helps a little - ddk ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.024 14:45:2 ADR760W (001)-FDSRL(01), DATA SET DMPRD.ACDS00.ACDS FROM CATALOG CATALOG.TECH. ADR489I (001)-TDLOG(02), CLUSTER DK85359.ACDS00.ACDS WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.ACDS00.ACDS.DATA ADR760W (001)-FDSRL(01), DATA SET DMPRD.BCOTS1.SCDS11.SCDS FROM CATALOG CATALO SPECIFIED ADR489I (001)-TDLOG(02), CLUSTER DK85359.BCOTS1.SCDS11.SCDS WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.BCOTS1.SCDS11.SCDS.DATA ADR760W (001)-FDSRL(01), DATA SET DMPRD.BCOTS1.TEST.CL FROM CATALOG CATALOG.TE ADR489I (001)-TDLOG(02), CLUSTER DK85359.BCOTS1.TEST.CL WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.BCOTS1.TEST.CL.DATA COMPONENT DK85359.BCOTS1.TEST.CL.INDEX This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 11:57:38 -0600, Mike Schwab wrote: >Even if it is copyrighted, it is an example expressly designated as a >sample to be modified and shared. > That makes sense. Is there a publication where I can find this? In writing? IBM publication? Or is this part of copyright law, covered by the doctrine of Fair Use? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
So maybe I'm totally off-base here, but it seems to me like the original request is that he wanted to know from the tape what kind of VSAM files were on the backup. I ran with my Restore with PARM='TYPERUN=NORUN' and got this from the output. Granted it's not fool proof. You can pick out the KSDS, the other 2 happen to be SMS datasets, so I know that they are LDS's - but as to RRDS, ESDS, etc Hope that helps a little - ddk ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.024 14:45:2 ADR760W (001)-FDSRL(01), DATA SET DMPRD.ACDS00.ACDS FROM CATALOG CATALOG.TECH. ADR489I (001)-TDLOG(02), CLUSTER DK85359.ACDS00.ACDS WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.ACDS00.ACDS.DATA ADR760W (001)-FDSRL(01), DATA SET DMPRD.BCOTS1.SCDS11.SCDS FROM CATALOG CATALO SPECIFIED ADR489I (001)-TDLOG(02), CLUSTER DK85359.BCOTS1.SCDS11.SCDS WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.BCOTS1.SCDS11.SCDS.DATA ADR760W (001)-FDSRL(01), DATA SET DMPRD.BCOTS1.TEST.CL FROM CATALOG CATALOG.TE ADR489I (001)-TDLOG(02), CLUSTER DK85359.BCOTS1.TEST.CL WAS SELECTED CATALOGUCAT.TSO.D COMPONENT DK85359.BCOTS1.TEST.CL.DATA COMPONENT DK85359.BCOTS1.TEST.CL.INDEX This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
IEFBR14 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, January 24, 2013 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Varying off path while it is in use Paul Gilmartin wrote: >Remember the Bad Old Days when the operator needed to submit a dummy job to >make a device actually go offline? (Or does it still work that way?) Geez, your memory is better than my decaying memory! Can you e-mail some [unused?] braincells to me? ;-D I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion years ago that I see that dummy job. I have searched NOW my RACF DB, procs, etc. Nothing there... Question: what was the PGM and parms used in that dummy job? Just curious of course! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Password (was: slightly O/T but interesting)
On Wed, 23 Jan 2013 13:31:31 -0600, John McKown wrote: >I can top that. On the Windows side a person called in because they >forgot their Windows login id (not password). At that time it was >first initial plus last name. How could they have forgotten who they >were, but remember where they worked? http://www.youtube.com/watch?v=pvn-tBeLpCk "You forgot your name?" "I been busy!" Regards, Art Gutowski -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
W dniu 2013-01-24 18:25, willie bunter pisze: Good Day All, Is there a way to differentiate or knowing what type of VSAM file it is. I had a problem earlier trying to RECATALOG the cluster (the dsn was restored from a physical DFDSS backup) and finally I was able to do so because I used parm NONINDEXED. Besides trial and error is there a way of doing this? I checked the LISTCAT however I didn't see anything. Any suggestions? Wild suggestion: forget about LISTCAT, because it would list the attribute (INDEXED, etc.) from catalog (BCS) entry (*), but the entry does not exist. Try to look at VVDS - the component is described in that structure. (*) in regular case LISTCAT reads information from both BCS and VVDS entries. In this case we have no BCS entry. BTW: Where the VVDS is documented? I *don't* mean brief description in "Managing Catalogs". -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
I remember using "S X" a long time ago myself. There was no proclib member named X, the member would not be found, but allocation was driven away so the device went offline. This all worked fine until someone put a real member into SYS1.PROCLIB named "X" to do something special, not knowing what the operators were doing. Then surprising results happened. It's better to used the official method, namely "S DEALLOC". Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA t: +1.617.614.4503 • e: bfairch...@rocketsoftware.com • w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Thursday, January 24, 2013 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Varying off path while it is in use The behavior has changed. Used to be in MVT and early MVS that something needed to drive allocation to take a device offline. I personally have *never* used DEALLOC. Just a simple 'S X' (with no proc behind it) from the console was sufficient. >It is still shipped in SYS1.PROCLIB(DEALLOC). > Of course. Someone's JCL proc or MGCR might depend on it. And no DD statement. I remembered wrong. And no IBM copyright notice. Does that mean you could post it here, or is it copyright regardless of notice? But the one I see has been customized locally to add accounting information to the JOB statement. (The account number is obsolete by two corporate acquisitions and more.) Did the behavior of VARY really change, or is it just that on a contemporary z/OS system the mean time between allocations is imperceptibly short? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 14:15:26 -0500, Gerhard Postpischil wrote: >On 1/24/2013 12:45 PM, Staller, Allan wrote: >> The behavior has changed. Used to be in MVT and early MVS that something >> needed to drive allocation to take a device offline. >> I personally have *never* used DEALLOC. Just a simple 'S X' (with no proc >> behind it) from the console was sufficient. > > >Under OS/360 a 'S X' command without any proc was sufficient. MVS came >with a DEALLOC proc, consisting of an IEFBR14 and comments cards >explaining the use. I routinely assigned X as an alias to it. > > De facto standard. I think every shop I ever worked in had a copy of DEALLOC named "X" so operators could just use "S X". In Allan's case, it was probably also true. I don't know if starting a non existent PROC (which would generate a JCL error) would do anything. Can't go back and test it now - but someone should be able to. There are lots of pre z/OS 1.7 systems floating around out there still, including ones running on Herc. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On 1/24/2013 12:45 PM, Staller, Allan wrote: The behavior has changed. Used to be in MVT and early MVS that something needed to drive allocation to take a device offline. I personally have *never* used DEALLOC. Just a simple 'S X' (with no proc behind it) from the console was sufficient. Under OS/360 a 'S X' command without any proc was sufficient. MVS came with a DEALLOC proc, consisting of an IEFBR14 and comments cards explaining the use. I routinely assigned X as an alias to it. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
Do you have a backup of the appropriate catalog from the same time period? That should have the information you are looking for. -- Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.gov "There is no instance of a country having benefited from prolonged warfare." ~ Sun Tzu -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, 24 January 2013 11:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DIFFERENTIATION OF VSAM DSNS Boris, Thanks for the valuable information. One last question. With the problem I encountered, since the dataset was restored from a physical DFDSS backup, only the DATA component was restored. I tried the LISTCAT of the .DATA component and since there was no cluster the LISTCAT was unsuccessful. In this case, how would I be able to tell what type of VSAM dsn it is? From: Boris Lenz To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, January 24, 2013 1:00:54 PM Subject: Re: DIFFERENTIATION OF VSAM DSNS On Thu, January 24, 2013 18:25, willie bunter wrote: > I checked the LISTCAT however I didn't see anything. Any suggestions? Examine the output of LISTCAT ENT(/) ALL. KSDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has an INDEXED ATTRIBUTE in the DATA section. VRRDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. ESDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NONINDEXED ATTRIBUTE in the DATA section. LDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a LINEAR ATTRIBUTE in the DATA section. RRDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
Boris, Thanks for the valuable information. One last question. With the problem I encountered, since the dataset was restored from a physical DFDSS backup, only the DATA component was restored. I tried the LISTCAT of the .DATA component and since there was no cluster the LISTCAT was unsuccessful. In this case, how would I be able to tell what type of VSAM dsn it is? From: Boris Lenz To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, January 24, 2013 1:00:54 PM Subject: Re: DIFFERENTIATION OF VSAM DSNS On Thu, January 24, 2013 18:25, willie bunter wrote: > I checked the LISTCAT however I didn't see anything. Any suggestions? Examine the output of LISTCAT ENT(/) ALL. KSDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has an INDEXED ATTRIBUTE in the DATA section. VRRDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. ESDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NONINDEXED ATTRIBUTE in the DATA section. LDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a LINEAR ATTRIBUTE in the DATA section. RRDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
These suggestions work if you did a query before it was deleted. Anything on the backup tape to indicate which one it is? > From: willie bunter > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/24/2013 11:25 AM > Subject:DIFFERENTIATION OF VSAM DSNS > Sent by:IBM Mainframe Discussion List > > > > Good Day All, > > Is there a way to differentiate or knowing what type of VSAM file it is. > I had a problem earlier trying to RECATALOG the cluster (the dsn was > restored from a physical DFDSS backup) and finally I was able to do so > because I used parm NONINDEXED. Besides trial and error is there a way of > doing this? > > I checked the LISTCAT however I didn't see anything. Any suggestions? > > Thanks -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
Check Section B.2.3 Attributes group to differentiate the VSAM clusters in below link which talks about Interpreting LISTCAT Output Listings. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I2A0/B.0? The keywords you would be interested are INDEXED--The data component has an index; it is key-sequenced aka KSDS. LINEAR--The cluster is a linear data set aka LDS NONINDEXED--The data component has no index; it is entry-sequenced aka ESDS. NUMBERED--The cluster is a relative record data set aka RRDS. Sri IBM Mainframe Discussion List wrote on 01/24/2013 09:25:07 AM: > From: willie bunter > To: IBM-MAIN@listserv.ua.edu, > Date: 01/24/2013 09:29 AM > Subject: DIFFERENTIATION OF VSAM DSNS > Sent by: IBM Mainframe Discussion List > > Good Day All, > > Is there a way to differentiate or knowing what type of VSAM file it > is. I had a problem earlier trying to RECATALOG the cluster (the > dsn was restored from a physical DFDSS backup) and finally I was > able to do so because I used parm NONINDEXED. Besides trial and > error is there a way of doing this? > > I checked the LISTCAT however I didn't see anything. Any suggestions? > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
On Thu, January 24, 2013 18:25, willie bunter wrote: > I checked the LISTCAT however I didn't see anything. Any suggestions? Examine the output of LISTCAT ENT(/) ALL. KSDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has an INDEXED ATTRIBUTE in the DATA section. VRRDS: - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. ESDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NONINDEXED ATTRIBUTE in the DATA section. LDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a LINEAR ATTRIBUTE in the DATA section. RRDS: - has only a DATA ASSOCIATION in the CLUSTER section. - has a NUMBERED ATTRIBUTE in the DATA section. Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DIFFERENTIATION OF VSAM DSNS
The Organization field in Fileaid will display this information for you. Use the VSAM Utility which for me is option 3.5. Bill Oczak Assurant Inc. From: willie bunter To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/24/2013 11:25 AM Subject:DIFFERENTIATION OF VSAM DSNS Sent by:IBM Mainframe Discussion List Good Day All, Is there a way to differentiate or knowing what type of VSAM file it is. I had a problem earlier trying to RECATALOG the cluster (the dsn was restored from a physical DFDSS backup) and finally I was able to do so because I used parm NONINDEXED. Besides trial and error is there a way of doing this? I checked the LISTCAT however I didn't see anything. Any suggestions? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
Even if it is copyrighted, it is an example expressly designated as a sample to be modified and shared. On Thu, Jan 24, 2013 at 11:42 AM, Paul Gilmartin wrote: > And no IBM copyright notice. Does that mean you could post it > here, or is it copyright regardless of notice? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
The behavior has changed. Used to be in MVT and early MVS that something needed to drive allocation to take a device offline. I personally have *never* used DEALLOC. Just a simple 'S X' (with no proc behind it) from the console was sufficient. >It is still shipped in SYS1.PROCLIB(DEALLOC). > Of course. Someone's JCL proc or MGCR might depend on it. And no DD statement. I remembered wrong. And no IBM copyright notice. Does that mean you could post it here, or is it copyright regardless of notice? But the one I see has been customized locally to add accounting information to the JOB statement. (The account number is obsolete by two corporate acquisitions and more.) Did the behavior of VARY really change, or is it just that on a contemporary z/OS system the mean time between allocations is imperceptibly short? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 09:50:57 -0600, Mary Anne Matyaz wrote: >It is still shipped in SYS1.PROCLIB(DEALLOC). > Of course. Someone's JCL proc or MGCR might depend on it. And no DD statement. I remembered wrong. And no IBM copyright notice. Does that mean you could post it here, or is it copyright regardless of notice? But the one I see has been customized locally to add accounting information to the JOB statement. (The account number is obsolete by two corporate acquisitions and more.) Did the behavior of VARY really change, or is it just that on a contemporary z/OS system the mean time between allocations is imperceptibly short? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling facility - Non Volatile performance
We've been doing parallel sysplex since 1995. I've never heard of any
performance implication. It's all about structure placement: some
exploiters insist on placing their structures in nonvolatile CFs. We've
run 'nonvolatile' for so long that I forget the gritty details, but I'm
pretty sure that in the olden days at least, JES2 was unhappy about a
volatile environment for the checkpoint structure (if used) .
So who actually decides if a CF is volatile or not? YOU do. It's a matter
of assertion, not hardware budget. On the HMC, select a CF LPAR and open
Operating System Messages. You can determine the current setting of this
option with the command
display mode
You will see 'MODDE is {NON}VOLATILE'
If it shows VOLATILE, issue the command
mode nonvolatile
Any application that queries CF volatility will now be told that the CF is
nonvolatile. In our case, we have a robust UPS with multiple utility feeds
(yes, we're a utility) and generator backup. We have never sprung for the
internal battery option, but we don't lose sleep over it. Note that MODE
setting applies to each CF LPAR, so you must perform these actions on all
CF LPARs on all CECs.
I suggest checking MODE via HMC as a good exercise, but OS 'DISPLAY CF'
will also tell you if you need to take action.
Like most CF options, MODE is retained across activations, e.g. POR.
However, any time you get a new CEC or undergo serious modifications to an
existing CEC, recheck and if necessary adjust the MODE. Same goes for
DYNDISP, topic for different discussion.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: "Vernooij, CP - SPLXM"
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 01/23/2013 11:54 PM
Subject:Re: Coupling facility - Non Volatile performance
Sent by:IBM Mainframe Discussion List
Barbara,
I would have expected you to mention option 3. as first option. Or do I
really sense a careful positivism towards HCs from you in the last year
;-)?
I would add another option: set up you CFs and structures in such a way,
that you can stand CF failures. Many applications can survive a CF
failure by rebuilding the structure in the other CF, others can keep on
working with duplexing, either user- or system-managed. The same applies
to failure isolation.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of nitz-...@gmx.net
Sent: Thursday, January 24, 2013 07:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coupling facility - Non Volatile performance
> >Due to IBM Health checker report we have to change mode of our
Coupling facility to non Volatile.. CF is running in a partition on CPC,
shared by 4 z/OS LPARs making it a sysplex. We are enabled for CICSPlex
, DB2 Data sharing, RACF Database Sharing, SMSPlex, Catalog ECS etc
etc..
> >
> >Can someone point me in the right direction to measure performance
gain (due to change of CF Mode) , if any.
> >
> >We are RMF, SAS/MXG and BMC Performance assurance (aka Visualiser,
Best/1 ) site.
> >
>
> A volatile coupling facility is one in which interruption of
the power supply causes loss of the memory contents. You can make the
coupling facility nonvolatile by adding to it an uninterruptible power
supply or you can use a battery backup, which uses internal batteries to
provide power during an outage.
We are talking about the XCF_CF_STR_NONVOLATILE check, right? Before
going to the expense of adding a battery or power supply (or - IIRC -
just fake it by setting the appropriate switch for the CF somewhere in
the HMC, which was possible in the past), read up carefully what the
health check says: It doesn't just talk about non-volatility. In essence
it talks about non-volatility *and* failure isolation. (Read up on both
in 'setting up a sysplex'.) Making the CF non-volatile will NOT make the
exception disappear as long as your CF runs on the same *hardware* as
any of the z/OSs that use this CF.
You have the following chances of making this exception disappear:
1. Make sure that no z/OS that uses the CF is on the same hardware as
the CF (failure isolation) *and* provide the battery to that hardware
(non-volatility).
2. Buy a standalone CF (failure isolation) with the appropriate battery
(non-volatility).
3. Delete this health check and go on as before (just for completeness).
>From the top of my head, structures that would like to have a
non-volatile, failure-isolated CF are typically system logger
structures. Assuming that you configured them correctly, they will
already automatically be duplexing data written to the CF to staging
data sets. Which will give you the result you need: In case of power
failure to the hardware your z/OS runs on, there is a copy of the data
still available somewhere (in this case, staging data sets). You will
gain a small benefit in pe
Re: Varying off path while it is in use
It is still shipped in SYS1.PROCLIB(DEALLOC). MA On Thu, 24 Jan 2013 08:41:53 -0600, Elardus Engelbrecht wrote: >Paul Gilmartin wrote: > >>Remember the Bad Old Days when the operator needed to submit a dummy job to >>make a device actually go offline? (Or does it still work that way?) > >Geez, your memory is better than my decaying memory! Can you e-mail some >[unused?] braincells to me? ;-D > >I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion years >ago that I see that dummy job. I have searched NOW my RACF DB, procs, etc. >Nothing there... > >Question: what was the PGM and parms used in that dummy job? > >Just curious of course! > >Groete / Greetings >Elardus Engelbrecht > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 08:51:10 -0600, Alan Field wrote: >I seem to recall a S DEALLOC command issued from the console (console >being a modified SELECTRIC typewriter) > >and > >//DEALLOC PROC >//S1 EXEC PGM=IEFBR14 > I thought you needed a DD statement, also. Was this because the allocation code was swappable? On Jan 24, 2013, at 08:02, Vernooij, CP - SPLXM wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, January 24, 2013 14:53 >Yup. About windoze, try removing your USB stick while something is writing on >it. Safety of contents on that stick is NOT guaranteed. Or do a CD/DVD >eject >while doing a pirate copy of something... BTDT. ;-D >If you compare, compare equal situations: I don't think z/OS will do better if >you pull out the only channel to a device it is writing to... Yup. I was thinking, for reference, about a demountable disk pack. Clearly the USB socket needs a little claw to grasp the stick until it's logically unmounted. "...do a CD/DVD >eject while..." How? Physically yank it out of the slot? Or eject it with Exploder? OS X won't let you do that while files are open. Can Windows be so stupid? I thought the mechanical eject button was disabled while the volume was mounted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC-SE Interoperability
Update I checked Technical Guides for EC12, z196 and z10. z10 guide has no chapter about HMC Both EC12 and z196 contain tables of compatibility SE to current (at the time of redbook writing) version of HMC. The tables show that even z990 machines are supported. This is also my knowledge and my experience. However I'm trying to connect SE 2.9.2 to HMC 2.10.2 and it's impossible. "The target is not at the proper release level. The target is release level 2.9.2. The minimum release level for this operation is 2.10.1. ACT38080” The operation performed was ...communication test. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 08:54:21 -0600, John McKown wrote: >I remember this too. I just tried a VARY dasdunit,OFFLINE on z/OS 1.12 >and it immediately went off line, with the message being issued. > >We had a started task called DEALLOC > >S DEALLOC > >it looked like: > >//DEALLOC EXEC PGM=IEFBR14 > >All it did was cause a step start, which went through ALLOCATION, >which is what seemed to drive the message. > Right, you no longer need to do this. I should know when this change happened, but a lot of allocation changes were made in phases over at least a couple of OS releases. That being said, I'm pretty sure this change happened at z/OS 1.7 (which is perhaps why I am fuzzy since the shop I was at skipped from 1.6 to 1.8). Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, January 24, 2013 14:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Varying off path while it is in use John McKown wrote: >The path is only needed while the SSCH is active (i.e. actual I/O is being >done). During this time, z/OS will not take the path offline. It will mark >>the path as pending offline and not use it for future I/O. Once the I/O is >complete, it will actually take the path offline. So, you should not need to >>worry. z/OS is a bit smarter than some of the other systems out their >(*cough* Windows *cough*). > >Yup. About windoze, try removing your USB stick while something is writing on >it. Safety of contents on that stick is NOT guaranteed. Or do a CD/DVD >eject >while doing a pirate copy of something... BTDT. ;-D If you compare, compare equal situations: I don't think z/OS will do better if you pull out the only channel to a device it is writing to... 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC-SE Interoperability
W dniu 2013-01-24 15:51, Mark Zelden pisze: On Thu, 24 Jan 2013 15:30:23 +0100, R.S. wrote: Where can I find information about supported HMC-SE code levels? AFAIK, in the old days I could connect HMC 2.9 to SE 1.8, despite 2.9 was Linux-based and SE was OS/2 based. Now I cannot connect HMC-SE 2.9 to 2.10 (and vice versa), because of unsupported levels. Do you have access to resource link and the hardware manuals for your mainframe(s)?I haven't looked though all of them, but I would think something should be in either the PR/SM manual, the HMC manuals or the SE manuals. Another place is the Technical Guide Redbook for your hardware model. For example, in the zEC12 Technical Guide chapter 12 (HMC & SE) contains information. Mark, I started from RTFM, actually HMC guide. However I didn't browse the redbook, thank you for the hint. BTW: HMC guide has no clue about supported system levels. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
I remember this too. I just tried a VARY dasdunit,OFFLINE on z/OS 1.12 and it immediately went off line, with the message being issued. We had a started task called DEALLOC S DEALLOC it looked like: //DEALLOC EXEC PGM=IEFBR14 All it did was cause a step start, which went through ALLOCATION, which is what seemed to drive the message. On Thu, Jan 24, 2013 at 8:41 AM, Elardus Engelbrecht wrote: > Paul Gilmartin wrote: > >>Remember the Bad Old Days when the operator needed to submit a dummy job to >>make a device actually go offline? (Or does it still work that way?) > > Geez, your memory is better than my decaying memory! Can you e-mail some > [unused?] braincells to me? ;-D > > I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion > years ago that I see that dummy job. I have searched NOW my RACF DB, procs, > etc. Nothing there... > > Question: what was the PGM and parms used in that dummy job? > > Just curious of course! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
I seem to recall a S DEALLOC command issued from the console (console being a modified SELECTRIC typewriter) and //DEALLOC PROC //S1 EXEC PGM=IEFBR14 Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 From: "Elardus Engelbrecht" To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/24/2013 08:42 Subject:Re: Varying off path while it is in use Sent by:IBM Mainframe Discussion List Paul Gilmartin wrote: >Remember the Bad Old Days when the operator needed to submit a dummy job to make a device actually go offline? (Or does it still work that way?) Geez, your memory is better than my decaying memory! Can you e-mail some [unused?] braincells to me? ;-D I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion years ago that I see that dummy job. I have searched NOW my RACF DB, procs, etc. Nothing there... Question: what was the PGM and parms used in that dummy job? Just curious of course! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this communication may be confidential, and is intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. Unencrypted, unauthenticated Internet e-mail is inherently insecure. Internet messages may be corrupted or incomplete, or may incorrectly identify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC-SE Interoperability
On Thu, 24 Jan 2013 15:30:23 +0100, R.S. wrote: >Where can I find information about supported HMC-SE code levels? >AFAIK, in the old days I could connect HMC 2.9 to SE 1.8, despite 2.9 >was Linux-based and SE was OS/2 based. >Now I cannot connect HMC-SE 2.9 to 2.10 (and vice versa), because of >unsupported levels. Do you have access to resource link and the hardware manuals for your mainframe(s)?I haven't looked though all of them, but I would think something should be in either the PR/SM manual, the HMC manuals or the SE manuals. Another place is the Technical Guide Redbook for your hardware model. For example, in the zEC12 Technical Guide chapter 12 (HMC & SE) contains information. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
Paul Gilmartin wrote: >Remember the Bad Old Days when the operator needed to submit a dummy job to >make a device actually go offline? (Or does it still work that way?) Geez, your memory is better than my decaying memory! Can you e-mail some [unused?] braincells to me? ;-D I only see [seldom] those MOUNT and UNLOAD commands, but it is gazillion years ago that I see that dummy job. I have searched NOW my RACF DB, procs, etc. Nothing there... Question: what was the PGM and parms used in that dummy job? Just curious of course! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HMC-SE Interoperability
Where can I find information about supported HMC-SE code levels? AFAIK, in the old days I could connect HMC 2.9 to SE 1.8, despite 2.9 was Linux-based and SE was OS/2 based. Now I cannot connect HMC-SE 2.9 to 2.10 (and vice versa), because of unsupported levels. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
On Thu, 24 Jan 2013 07:30:48 -0600, John McKown wrote: >The path is only needed while the SSCH is active (i.e. actual I/O is >being done). During this time, z/OS will not take the path offline. It >will mark the path as pending offline and not use it for future I/O. >Once the I/O is complete, it will actually take the path offline. So, >you should not need to worry. z/OS is a bit smarter than some of the >other systems out their (*cough* Windows *cough*). > I understand VSE used to work that way. Did it get better? Are we talking about possibly the only path? What if the device is allocated? Remember the Bad Old Days when the operator needed to submit a dummy job to make a device actually go offline? (Or does it still work that way?) It's been a long time since I've seen DEVICE IS NOW OFFLINE in my job log, or even on my OMVS terminal, where I recall once having seen one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
John McKown wrote: >The path is only needed while the SSCH is active (i.e. actual I/O is being >done). During this time, z/OS will not take the path offline. It will mark the >path as pending offline and not use it for future I/O. Once the I/O is >complete, it will actually take the path offline. So, you should not need to >worry. z/OS is a bit smarter than some of the other systems out their (*cough* >Windows *cough*). Yup. About windoze, try removing your USB stick while something is writing on it. Safety of contents on that stick is NOT guaranteed. Or do a CD/DVD eject while doing a pirate copy of something... BTDT. ;-D To the OP (Victor): I would like to add to what John kindly wrote, that if the I/O is completed, another LPAR may or may not pick up it [again] for more I/O work. I would suggest something like that: RO *ALL, and then wait for all remaining I/O to finish. You all need to check ALL the channels to a device are OFF on all LPARS and Sysplexes connected to it Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
On Thu, 24 Jan 2013 05:40:00 +0100, nitz-...@gmx.net wrote: >> I mentioned the AUTOIPL statement because it's easy to overlook. But yes, >> guaranteed that if there are multiple SAD output volumes, they need to be >> need to rebuilt using AMDSADDD because the volumes are chained together by >> unit address, which AMDSADDD determines and writes out. Guess how I know >> that for sure? ;-(( >Et tu? > >If you're mirroring DASD and have to cut over to the mirrored version, make >sure to either NOT mirror your sadump volumes (the ones housing the sadmp >dataset) or else always regen sadmp via AMDSADDD. > We don't mirror the output volumes, but the IPL volume is since it is on a secondary sysres or DLIB vol. So rebuilding SADUMP is one of the steps when we come up at our DR site. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Varying off path while it is in use
The path is only needed while the SSCH is active (i.e. actual I/O is being done). During this time, z/OS will not take the path offline. It will mark the path as pending offline and not use it for future I/O. Once the I/O is complete, it will actually take the path offline. So, you should not need to worry. z/OS is a bit smarter than some of the other systems out their (*cough* Windows *cough*). On Thu, Jan 24, 2013 at 7:22 AM, Victor Zhang wrote: > Hello experts, > One dumb question: > For a Storagetek VSM product or IBM TS7700 product, I can have multiple > channels connecting with them, I also know that a tape I/O must complete on > the path where it is initiated. Please correct me if I am wrong. > Based on this assumption, if there is a need to upgrade code in interface > cards of virtual tape products, I may need offline path to the interface > card I need service, is it OK to offline path to one of the interface card > while it may be in use? Will z/OS protect the path while there are any > outstanding I/O that don't complete? The bottom question is: Is it safe to > offline path or will it cause backup job(for example ADRDSSU) job to abend? > > Regards > Victor > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Varying off path while it is in use
Hello experts, One dumb question: For a Storagetek VSM product or IBM TS7700 product, I can have multiple channels connecting with them, I also know that a tape I/O must complete on the path where it is initiated. Please correct me if I am wrong. Based on this assumption, if there is a need to upgrade code in interface cards of virtual tape products, I may need offline path to the interface card I need service, is it OK to offline path to one of the interface card while it may be in use? Will z/OS protect the path while there are any outstanding I/O that don't complete? The bottom question is: Is it safe to offline path or will it cause backup job(for example ADRDSSU) job to abend? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mktg: New Release of SyzMPF/z available
דני - דוגמה לשיווק בIBM Mainframe Discussion List : On Thu, Jan 24, 2013 at 9:10 AM, Brian Westerman < brian_wester...@syzygyinc.com> wrote: Hi all, This is more of a marketing announcement (thus the subject line), but I wanted to let everyone on the list know, especially those customers who did not see the general announcement, that Version 3 of SyzMPF/z (automated console message processing), has come out of beta testing and is now G.A. This version had some major enhancements, including: Persistent Variables, which are persistent for the length of the IPL. Non-Persistent variables, which persistent only for the length of the Task that they were generated for. i.e. if a Non-persistent variable is generated for CICS001, when CICS001 terminates the variable is automatically removed. Enhanced Static Variables, a slew of static variables have been added like individual time and date portions, as well as hardware, software and sub-system related items that can be used as components of IF/THEN related testing or displayed in messages. New ability to "create your own" operator commands, structured and named however you want them to be which can perform any complex or simple script related function as well as the ability to be able to tell if a console message is generated from a task or was generated from a console command (i.e. issued by a real or virtual operator). Plus several other new features. Current customers will be receiving shipments of the new version of SyzMPF/z on their normal refresh schedule, but can request immediate shipment of this version any time starting January 25th. For more information please feel free to visit: http://www.syzygyinc.com/SyzMPFz.htm you can download the manual from that same page above or: http://www.syzygyinc.com/Documents/SyzMPFz%20V3.1%20Installation%20and%20Users%20Guide.pdf Thank you for your time and I apologize if you were not interested in this announcement. Brian Westerman Syzygy Incorporated -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: OMVS deleted files/directories.
Hi
USS SMF records have some self-defining sections. ICETOOL needs fix offsets,
therefore I use REXX.
Here the SMF recordtype 92 subtype 14 report extract:
vbsbytes= 4
/* */
process_record:
/* */
/* SMF Record Type 92 Subtype 14 */
/* Record Header Section */
smf92sid = substr(smf_record,14-vbsbytes+1,4) /* System ID */
smf92wid = substr(smf_record,18-vbsbytes+1,4) /* Subsystem ID */
/* Time field in hundredths of a second format */
/* is the number of seconds after midnight */
s92_tme = c2d(substr(smf_record,6-vbsbytes+1,4))
s92_hh = right(s92_tme % 36,2,'0') /* integer divide */
s92_hhr = s92_tme // 36 /* remainder */
s92_mm = right(s92_hhr % 6000,2,'0')
s92_mmr = s92_hhr // 6000
s92_ss = right(s92_mmr // 100,2,'0')
smf92tme = s92_hh!!'.'!!s92_mm!!'.'!!s92_hh
/* Date the record was written in the form 0cyydddF, (where c is*/
/* 0 for 19xx and 1 for 20xx, yy is the current year (0-99), ddd is */
/* the current day (1-366), and F is the sign for a packed field). */
s92_dte = c2x(substr(smf_record,10-vbsbytes+1,4))
/* convert julian to standard */
smf92dte = date('S',substr(s92_dte,3,5),'J')
/* Offset to subsys section */
smf92sof = c2d(substr(smf_record,28-vbsbytes+1,4))
/* Offset to ident. section */
smf92iof = c2d(substr(smf_record,36-vbsbytes+1,4))
offset_id = smf92iof - vbsbytes
r = ident_section()
/* Offset to data section */
smf92dof = c2d(substr(smf_record,44-vbsbytes+1,4))
offset_data = smf92dof - vbsbytes
r = data_section()
if r = zero then r = write_record()
return(r)
/* --- */
ident_section:
/* --- */
/* Identification Section */
smf92jbn = substr(smf_record,offset_id+1,8)/* Jobname */
smf92stm = substr(smf_record,offset_id+16+1,8) /* Stepname */
smf92rud = substr(smf_record,offset_id+32+1,8) /* User ID */
return(r)
/* -- */
data_section:
/* -- */
/* Subtype 14 */
smf92dfn = substr(smf_record,offset_data+72+1,64) /* delete fn */
return(r)
HTH
If you need the whole part please contact me offline
Albert
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von sunil mirchandani
Gesendet: Mittwoch, 23. Januar 2013 16:39
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Reg: OMVS deleted files/directories.
Hello Team,
Can any one help to find out who has deleted particular files/directories
under OMVS.
Do we have any command to check or any other way( Any utility/job which
takes SMF data as a input and generate some report to find the user who has
deleted).
Any help much appreciated.
Thanks & Regards:
Sunil Mirchandani
9742433311
"Yesterday I dared to struggle. Today I dare to win"
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VERLAGSGRUPPE WELTBILD GMBH
Sitz der Gesellschaft: Augsburg
Handelsregister Augsburg HRB 6035
Ust-ID-Nr: DE 127501299
Geschäftsführung:
Carel Halff (Vorsitzender), Dr. Martin Beer
Vorsitzender des Aufsichtsrats:
Generalvikar DDr. Peter Beer
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
