Re: Collecting SMF dataset using LogStream
This function has been available for years, long before z/OS V2. Google the following string. Pour yourself a large coffee and dig in. ibm smf logger . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of saurabh khandelwal Sent: Thursday, November 14, 2019 9:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Collecting SMF dataset using LogStream Hello Group, Currently we have z/OS 2.1 system and collecting SMF datasets using MAN1, MAN2 etc dataset and then during every smf switch, we extract records related to db2, cics, TCPIP, RMF in seperate datasets and then archive these dataset in regular basis. But we upgrading system to z/OS 2.3 and there is feature of using logsteam to collect smf records rather then using MAN datasets and then use seperate log stream for db2, cics, TCPIP and collect particular record type into that But I am unable to find any steps to configure these logsteam for these purpose. Can you please help me to do . Thanks for your help -- Thanks & Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Collecting SMF dataset using LogStream
Hello Group, Currently we have z/OS 2.1 system and collecting SMF datasets using MAN1, MAN2 etc dataset and then during every smf switch, we extract records related to db2, cics, TCPIP, RMF in seperate datasets and then archive these dataset in regular basis. But we upgrading system to z/OS 2.3 and there is feature of using logsteam to collect smf records rather then using MAN datasets and then use seperate log stream for db2, cics, TCPIP and collect particular record type into that But I am unable to find any steps to configure these logsteam for these purpose. Can you please help me to do . Thanks for your help -- Thanks & Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How can I generate a UUID in a z/OS COBOL Program
In my case the requirement for a UUID is from a CICS program. It is my
understanding that OO COBOL is not supported under CICS. Can Java applications
be called by CICS programs using EXEC CICS LINK? In any case I don't think
adding Java to our environment, where Java is not currently be using by "user
applications", is a good way to go.
Our requirement for the UUID is not immediate, so I don't see any reason to not
wait for COBOL built in support; assuming UUID Version 4 is supported.
Frank
From: IBM Mainframe Discussion List on behalf of
Timothy Sipples
Sent: Thursday, November 14, 2019 12:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I generate a UUID in a z/OS COBOL Program
Frank Swarbrick wrote:
>The SWIFT payments network has a field called the UETR
>(Unique End-to-end Transaction Reference), which is a
>Version 4 UUID. Will the new Enterprise COBOL feature
>be able to generate a Version 4 UUID?
You can already generate version 4 UUIDs via INVOKE to a small -- really,
really small -- bit of Java code. Here's a basic Java sample to generate a
version 4 UUID:
import java.util.UUID;
class UUIDSample
{
public static void main(String arg[]) throws
UnsupportedOperationException
{
UUID v4uuid = UUID.randomUUID();
// Then do what you want with v4uuid here
// (Return it, for example)
}
}
SWIFT may or may not need something more than a IETF RFC 4122 version 4
UUID.
This approach works with all z/OS and Enterprise COBOL releases that are
still in service, plus some past releases that have reached End of Service.
java.util.UUID was introduced all the way back in Java 5, for example. (The
Java 5 SDK for z/OS was released on December 16, 2005, and reached End of
Service on September 30, 2013.) I can't remember when INVOKE was first
introduced, but it was a long time ago.
Moreover, if you're concerned about entropy, my understanding with this
code sample is that it'll automatically benefit from the True Random Number
Generator (TRNG) included in the IBM z14 and later processors, just as long
as your Java Runtime Environment is recent enough (which is not
particularly recent at this point) to be aware of the TRNGs. On earlier
models you could presumably ask Crypto Express to provide a TRN to the JRE,
with a few more Java Cryptography Extension (JCE)-related lines of code I
imagine.
In short, while UUID (including UUID version 5) functions in Enterprise
COBOL and/or Language Environment would be most welcome in my view, you
don't have to wait, and you shouldn't wait. Solve the problem you have, and
it's very easy to solve, right now.
If somebody wants to raise an objection such as "Oh, I can't do that --
that's another language," then my basic response is "Don't be silly." JCL,
DL/I, and SQL are also languages that aren't COBOL, and so what? A COBOL
programmer would hardly be a competent one without knowing a little bit
about some other languages, enough to be useful and productive anyway. Two
of those three aren't included in the base z/OS operating system, as it
happens, but Java is. Did the English language wait to arrive at some
consensus alternative instantiations of the words sushi, taxi, and detente,
as examples? INVOKE is there for a reason (and has been for well over a
decade), so use it!
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com
--
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: DFDSS backup retore
That's the ticket. Thx... In a message dated 11/14/2019 3:11:20 AM Central Standard Time, 0224d287a4b1-dmarc-requ...@listserv.ua.edu writes: Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
XXOUTDD1DD DSN=BACKUP.DLY.(+1), XX DISP=(NEW,CATLG,DELETE),UNIT=, XX VOL=,LABEL=(,SL,EXPDT=99000) IEFC653I SUBSTITUTION JCL - DSN=BACKUP.DLY.SMFLGB(+1),DISP=(NEW,CATLG,DELETE),UNIT=TAPE3592,VOL=(,RETAIN,,10), LABEL=(1,SL,EXPDT=99000) DUMP -. . ADMIN- . . INDDNAME(INDD1) OUTDDNAME(OUTDD1) - . . ALLDATA(*) FULL ALLEXCP - . . OPTIMIZE(4) Dean Nai On 11/14/19, 11:41 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, David" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Not why I asked. Just wondering why you think you need to specify those. Can >you post the JCL in its entirety used to create the backups? > >Looking at the tape label you posted separately, I cannot decipher all the >fields definitively without the headers, but I see RECFM=U, I just don’t know >what the next numbers are. Also, what specific type of tape device are you >using? > >>> L.SMFLGB.G0303V00 19.287 99.000 U25458 200 >>> P1274 1274 SYSFBK1W/BACKUP > >But one of my DSS VOLUME dumps looks like this > >VOLSER = E55759 ACTVOL=SMSMC= BLANKS >DSN= TPE.TDP..DLB01A.D191022DSN17= >58.DLB01A.D191022 >EXPDT = CATALOGACCT= BLANKS >FLAG1 = 41 FLAG2 = C0 FLAG3 = 00 BATCHID= 00 = >FLAG4 = 08 FLAG5 = 00 FLAG6 = 00 HOOKID = FD = SMF 83 >EDMID =WMC= 0WWID = - - >CDATE = 2019/295 CJOB = CTIME = 0855 CPGM = ADRDSSU >LDATE = 2019/295 LJOB = LTIME = 0855 LPGM = ADRDSSU >CSTEP = VOLDUMPCDDNAME= TAPE2CUNIT = 20CE LUNIT = 20CE >OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 >BTHDATE= 2007/125 VENDOR = BLANKS COUNT = 00264TWERRC = 0 >DATECLN= ZEROS USECLN = 0CLNCNT = 000 TRERRI = 0 >VOLSEQ = 0001 ROBTY = VIBM ROBID = 001 TWERRI = 0 >1STVOL =NEXTVOL= PREVVOL= PRERRC = 0 >NUMDSNB= 0 1STDSNB= LSTDSNB= PWERRC = 0 >LABEL = SL DEN= 38KC TRTCH = 36X2 PRERRI = 0 >RECFM = U LRECL = 00 BLKSIZE= 262144 PWERRI = 0 >AUDATE = 2019/295 AUTIME = 0858 BESKEY = 0BLKCNT = 052020 >AUCODE = 02 AUFLAG1= 00 CPUID = TEC1 USERID = CATALOG >VOLPERC= 001 FILPERC= 001 COMPRES= 043 BYTEPRC= 080 CTLGCNT= 001 > >_ >Dave Jousma >AVP | Manager, Systems Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, >MI 49546 >616.653.8429 | fax: 616.653.2717 > > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Nai, Dean >Sent: Thursday, November 14, 2019 11:16 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DFDSS backup retore > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >Hi Dave, > > Tried both. >Dean Nai > > > > > > > > > >On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, >David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize >> and trust the sender. >> >>Why are you specifying label and volser info for the input? >> >>___ >>__ >>Dave Jousma >>AVP | Manager, Systems Engineering >> >>Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >>Rapids, MI 49546 >>616.653.8429 | fax: 616.653.2717 >> >> >> >>-Original Message- >>From: IBM Mainframe Discussion List On >>Behalf Of Nai, Dean >>Sent: Thursday, November 14, 2019 10:38 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: DFDSS backup retore >> >>**CAUTION EXTERNAL EMAIL** >> >>**DO NOT open attachments or click on links from unknown senders or >>unexpected emails** >> >>The restore job gets the same error message for all restores. This time I >>tried using a weekly backup instead of a daily backup. That got the same >>error. >> >> >> >> >> >> >> >>This e-mail
Re: DFDSS backup restore
As I recall, this was endemic to DF/DSS at the time. The z/OS 1.12 version would not (by default) read the "old backup" (z/OS 1.11 or below). There is/was a PARM= or ctlcard option that needed to be specified in order to read a dump dataset created by the "old version". Of course , given the age of this apar (circa 2015) it may not be applicable. i.e. the data being restored would need to have been created prior to the installation of this APAR. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Thursday, November 14, 2019 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS backup retore Hi Dean, In case you're running Oracle (Sun (STK)) VSM, please see: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.oracle.com%2Fknowledge%2FSun%2520Microsystems%2F1284809_1.htmldata=02%7C01%7Callan.staller%40HCL.COM%7C1b391799744f4a932d4708d769070f9f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637093351385087661sdata=ZACuymeHxEqGXxPUTvKATeaWKvtevzAz2apyYtDyF2c%3Dreserved=0 Regards, David On 2019-11-14 08:22, Nai, Dean wrote: > Hi Carmen, > We tried using both catalog and VOL=SER=. Both failed. > > > > > > > > On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen > Vitullo" wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize >> and trust the sender. >> >> norun will only syntax check your parms, control cards, are you using the >> catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? >> >> >> >> Carmen Vitullo >> >> - Original Message - >> >> From: "Dean Nai" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Thursday, November 14, 2019 6:48:48 AM >> Subject: Re: DFDSS backup retore >> >> Hi Mark, >> >> Ran the job with the NORUN part and it got a RC=0. Not sure what that proved >> but maybe something. I then dumped the tape label and it looks good although >> as we know it only shows the last 17 characters. I used one of the other >> tapes that had the same error for the tape label dump. >> >> L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 >> SYSFBK1W/BACKUP >> >> >> >> >> >> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE >> IN NORUN MODE RESTORE - ADMIN - >> INDDNAME(INDD1) OUTDDNAME(OUTDD1) - >> FULL COPYVOLID PURGE >> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' >> ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER >> CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING >> OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.318 >> 06:31:46 EXECUTION BEGINS ADR040I (001)-TDFP (01), PROCESSING >> BYPASSED DUE TO NORUN OPTION ADR006I (001)-STEND(02), 2019.318 >> 06:31:46 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.318 06:31:46 >> TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), >> 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE >> IS >> >> >> >> >> Dean Nai >> >> >> >> >> >> >> >> >> On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark >> Jacobs" > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: >> >>> EXTERNAL: Do not open attachments or click on links unless you recognize >>> and trust the sender. >>> >>> Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. >>> >>> Mark Jacobs >>> >>> >>> Sent from ProtonMail, Swiss-based encrypted email. >>> >>> GPG Public Key - >>> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur >>> ldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup >>> %3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!eeWmBe9sc1cu >>> Nw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaX >>> Q%24data=02%7C01%7Callan.staller%40HCL.COM%7C1b391799744f4a932d >>> 4708d769070f9f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63709335 >>> 1385087661sdata=V6fyTAtgRsOp4K7NISSGWWRoDPXH755mvbfbr5GU2A4%3D& >>> amp;reserved=0 >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, November 13, 2019 8:42 PM, Edward Finnell >>> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: >>> Is there a DSS function to list the contents of the backup? We were FDR and it was straight forward. In a message dated 11/13/2019 6:59:32 PM Central Standard Time, retired-mainfra...@q.com writes: The error has nothing to do with labels. DFDSS processed 32 blocks of data and reported a problem when reading the 33rd. --- --- --- --- - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the
Re: Around ASSBASST and ASSBPHTM time fields
> From: "M.V Ram" > > Hello, I have a question regarding the ASSBASST and ASSBPHTM fields > of ASSB control block. > > To explain it better, I am quoting this example. > > Say, an address space 'A' schedules a "preemptable SRB S1" on > itself. Another address space 'B' schedules a "preemptable SRB S2" > into the address space 'A' and another address space 'C' schedules an >"Enclave SRB S3" into the address space 'A' > > So, there are three SRBs running under address space A. S1 = Preemptable > SRB Scheduled by 'A' into itself S2 = Preemtable SRB scheduled by 'B' > S3 = Enclave SRB scheduled by 'C' > > Q1: My understanding is, at any point of time while all SRBs are being > executed in address space 'A', the ASSBASST of address space 'A' = > CPU time consumed by S1 + CPU time consumed by S2. > > It doesn't include the CPU time consumed by S3 because it is an enclave > SRB. Is this the correct understanding? > > Q2. When the SRBs are being executed, the ASSBPHTM of address space > 'A' = CPU time consumed by S1 + S2 + S3. Because PHTM is for all types > of SRBs. Is this the correct understanding? > > Q3. So the delta between PHTM and ASST would always result in the pure enclave > SRB CPU time of that address space? Although those fields predate my experiences with MVS, I think you will find that those fields are only updated with CPU from the SRB routine use after some types interrupts of the SRB routines involved. I would usually expect this "interrupt" to be the SRB routine termination, but other reasons (page fault?, wait for lock?, preemption?) might get those ASSB CPU time fields updated with CPU time "used so far" sooner. So if the 3 SRBs are currently running (on 3 different CPUs) then none of the fields are likely to have been updated (yet) with the CPU they are using... My best guess... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM-main -L
IBM-MAIN -L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
Not why I asked. Just wondering why you think you need to specify those. Can you post the JCL in its entirety used to create the backups? Looking at the tape label you posted separately, I cannot decipher all the fields definitively without the headers, but I see RECFM=U, I just don’t know what the next numbers are. Also, what specific type of tape device are you using? >> L.SMFLGB.G0303V00 19.287 99.000 U25458 200 >> P1274 1274 SYSFBK1W/BACKUP But one of my DSS VOLUME dumps looks like this VOLSER = E55759 ACTVOL=SMSMC= BLANKS DSN= TPE.TDP..DLB01A.D191022DSN17= 58.DLB01A.D191022 EXPDT = CATALOGACCT= BLANKS FLAG1 = 41 FLAG2 = C0 FLAG3 = 00 BATCHID= 00 = FLAG4 = 08 FLAG5 = 00 FLAG6 = 00 HOOKID = FD = SMF 83 EDMID =WMC= 0WWID = - - CDATE = 2019/295 CJOB = CTIME = 0855 CPGM = ADRDSSU LDATE = 2019/295 LJOB = LTIME = 0855 LPGM = ADRDSSU CSTEP = VOLDUMPCDDNAME= TAPE2CUNIT = 20CE LUNIT = 20CE OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 BTHDATE= 2007/125 VENDOR = BLANKS COUNT = 00264TWERRC = 0 DATECLN= ZEROS USECLN = 0CLNCNT = 000 TRERRI = 0 VOLSEQ = 0001 ROBTY = VIBM ROBID = 001 TWERRI = 0 1STVOL =NEXTVOL= PREVVOL= PRERRC = 0 NUMDSNB= 0 1STDSNB= LSTDSNB= PWERRC = 0 LABEL = SL DEN= 38KC TRTCH = 36X2 PRERRI = 0 RECFM = U LRECL = 00 BLKSIZE= 262144 PWERRI = 0 AUDATE = 2019/295 AUTIME = 0858 BESKEY = 0BLKCNT = 052020 AUCODE = 02 AUFLAG1= 00 CPUID = TEC1 USERID = CATALOG VOLPERC= 001 FILPERC= 001 COMPRES= 043 BYTEPRC= 080 CTLGCNT= 001 _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Thursday, November 14, 2019 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS backup retore **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi Dave, Tried both. Dean Nai On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, David" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Why are you specifying label and volser info for the input? > >___ >__ >Dave Jousma >AVP | Manager, Systems Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >Rapids, MI 49546 >616.653.8429 | fax: 616.653.2717 > > > >-Original Message- >From: IBM Mainframe Discussion List On >Behalf Of Nai, Dean >Sent: Thursday, November 14, 2019 10:38 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DFDSS backup retore > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or >unexpected emails** > >The restore job gets the same error message for all restores. This time I >tried using a weekly backup instead of a daily backup. That got the same error. > > > > > > > >This e-mail transmission contains information that is confidential and may be >privileged. It is intended only for the addressee(s) named above. If you >receive this e-mail in error, please do not read, copy or disseminate it in >any manner. If you are not the intended recipient, any disclosure, copying, >distribution or use of the contents of this information is prohibited. Please >reply to the message immediately by informing the sender that the message was >misdirected. After replying, please erase it from your computer system. Your >assistance in correcting this error is appreciated. > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail
Re: Tracking called (non-main) programs using SMF records
Write your own CSV exit to knock out an SMF record for these called programs. I have done this several times and only once missed anything because some smartie pants from CA was doing his own program loads. On Thu, Nov 14, 2019 at 3:59 AM Massimo Biancucci wrote: > Hi, > > as other colleagues already said, no standard SMF way. > > At my customers sites, they use TADz (it seems Ptracker gives more > information like the chain between caller and called) and for some of them > a product we developed to correlate CICS-Transactions with LINKed/CALLed > programs (written to SMF records). > > About cleanup, if applicable, keep attention to static linked programs who > seem to be called by nobody. > > Best regards. > Max > > Il giorno mer 13 nov 2019 alle ore 17:07 Steff Gladstone < > steff.gladst...@gmail.com> ha scritto: > > > We would like to clean up our load libraries by deleting unused programs. > > > > Is there any way to use SMF data to track real-time usage of programs > which > > are not main programs but are called by other programs? > > > > We were under the impression that only executions of main programs > (PGM=) > > were recorded with SMF. Scanning program sources for called programs is > > unsatisfactory for us since the call could be dynamic (name of program > > contained in a variable) or conditional on a particular set of > > circumstances that never occurs in practice. > > > > Thanks in advance! > > > > Steff Gladstone > > > > -- > > 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: DFDSS backup retore
Hi Dave, Tried both. Dean Nai On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, David" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Why are you specifying label and volser info for the input? > >_ >Dave Jousma >AVP | Manager, Systems Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, >MI 49546 >616.653.8429 | fax: 616.653.2717 > > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Nai, Dean >Sent: Thursday, November 14, 2019 10:38 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DFDSS backup retore > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >The restore job gets the same error message for all restores. This time I >tried using a weekly backup instead of a daily backup. That got the same error. > > > > > > > >This e-mail transmission contains information that is confidential and may be >privileged. It is intended only for the addressee(s) named above. If you >receive this e-mail in error, please do not read, copy or disseminate it in >any manner. If you are not the intended recipient, any disclosure, copying, >distribution or use of the contents of this information is prohibited. Please >reply to the message immediately by informing the sender that the message was >misdirected. After replying, please erase it from your computer system. Your >assistance in correcting this error is appreciated. > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to 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: DFDSS backup retore
Why are you specifying label and volser info for the input? _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Thursday, November 14, 2019 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS backup retore **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** The restore job gets the same error message for all restores. This time I tried using a weekly backup instead of a daily backup. That got the same error. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
The restore job gets the same error message for all restores. This time I tried using a weekly backup instead of a daily backup. That got the same error. On 11/14/19, 8:58 AMEST, "IBM Mainframe Discussion List on behalf of retired mainframer" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >In your first message, the LLQ was G0449V00. Now it is G0303V00. Are we >still talking about the same issue? > >One more time, the original error message did not relate to the label or DSN. > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Nai, Dean >> Sent: Thursday, November 14, 2019 4:49 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: DFDSS backup retore >> >> Hi Mark, >> >>Ran the job with the NORUN part and it got a RC=0. Not sure what that >> proved but >> maybe something. I then dumped the tape label and it looks good although as >> we >> know it only shows the last 17 characters. I used one of the other tapes >> that had the >> same error for the tape label dump. >> >> L.SMFLGB.G0303V00 19.287 99.000 U25458 200 >> P1274 >> 1274 SYSFBK1W/BACKUP > >-- >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
Throwback Thursday: Oh, sorry, did someone sell off half of YOUR capacity? | Computerworld
Watch for url wrapping https://www.computerworld.com/article/3444566/throwback-thursday-oh-sorry-did-someone-sell-off-half-of-your-capacity.html Regards, Mark Regan Sent from my Android phone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
In your first message, the LLQ was G0449V00. Now it is G0303V00. Are we still talking about the same issue? One more time, the original error message did not relate to the label or DSN. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Nai, Dean > Sent: Thursday, November 14, 2019 4:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFDSS backup retore > > Hi Mark, > >Ran the job with the NORUN part and it got a RC=0. Not sure what that > proved but > maybe something. I then dumped the tape label and it looks good although as we > know it only shows the last 17 characters. I used one of the other tapes that > had the > same error for the tape label dump. > > L.SMFLGB.G0303V00 19.287 99.000 U25458 200P >1274 > 1274 SYSFBK1W/BACKUP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
Hi Dean, In case you're running Oracle (Sun (STK)) VSM, please see: https://support.oracle.com/knowledge/Sun%20Microsystems/1284809_1.html Regards, David On 2019-11-14 08:22, Nai, Dean wrote: > Hi Carmen, > We tried using both catalog and VOL=SER=. Both failed. > > > > > > > > On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen > Vitullo" wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize >> and trust the sender. >> >> norun will only syntax check your parms, control cards, are you using the >> catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? >> >> >> >> Carmen Vitullo >> >> - Original Message - >> >> From: "Dean Nai" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Thursday, November 14, 2019 6:48:48 AM >> Subject: Re: DFDSS backup retore >> >> Hi Mark, >> >> Ran the job with the NORUN part and it got a RC=0. Not sure what that proved >> but maybe something. I then dumped the tape label and it looks good although >> as we know it only shows the last 17 characters. I used one of the other >> tapes that had the same error for the tape label dump. >> >> L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP >> >> >> >> >> >> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN >> MODE >> RESTORE - >> ADMIN - >> INDDNAME(INDD1) OUTDDNAME(OUTDD1) - >> FULL COPYVOLID PURGE >> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' >> ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL >> STATEMENTS COMPLETED >> ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK >> ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS >> ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION >> ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS >> ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE >> >> ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. >> HIGHEST RETURN CODE IS >> >> >> >> >> Dean Nai >> >> >> >> >> >> >> >> >> On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark >> Jacobs" > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: >> >>> EXTERNAL: Do not open attachments or click on links unless you recognize >>> and trust the sender. >>> >>> Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. >>> >>> Mark Jacobs >>> >>> >>> Sent from ProtonMail, Swiss-based encrypted email. >>> >>> GPG Public Key - >>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ%24data=02%7C01%7C%7Cbbae3136ff484aacd38c08d76905d087%7C84df9e7fe9f640afb435%7C1%7C0%7C637093346016362866sdata=heNINPkab1BaHySWa7zx0GVUUWgcp6Jxq%2B7aQac14BM%3Dreserved=0 >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, November 13, 2019 8:42 PM, Edward Finnell >>> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: >>> Is there a DSS function to list the contents of the backup? We were FDR and it was straight forward. In a message dated 11/13/2019 6:59:32 PM Central Standard Time, retired-mainfra...@q.com writes: The error has nothing to do with labels. DFDSS processed 32 blocks of data and reported a problem when reading the 33rd. - 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 >> >> >> -- >> 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 /
Re: DFDSS backup retore
Hi Carmen, We tried using both catalog and VOL=SER=. Both failed. On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen Vitullo" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >norun will only syntax check your parms, control cards, are you using the >catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? > > > >Carmen Vitullo > >- Original Message - > >From: "Dean Nai" >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Thursday, November 14, 2019 6:48:48 AM >Subject: Re: DFDSS backup retore > >Hi Mark, > >Ran the job with the NORUN part and it got a RC=0. Not sure what that proved >but maybe something. I then dumped the tape label and it looks good although >as we know it only shows the last 17 characters. I used one of the other tapes >that had the same error for the tape label dump. > >L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP > > > > > >ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN >MODE >RESTORE - >ADMIN - >INDDNAME(INDD1) OUTDDNAME(OUTDD1) - >FULL COPYVOLID PURGE >ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' >ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL >STATEMENTS COMPLETED >ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK >ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS >ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION >ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS >ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE > >ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. >HIGHEST RETURN CODE IS > > > > >Dean Nai > > > > > > > > >On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark >Jacobs" 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize and >> trust the sender. >> >>Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. >> >>Mark Jacobs >> >> >>Sent from ProtonMail, Swiss-based encrypted email. >> >>GPG Public Key - >>https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$ >> >> >>‐‐‐ Original Message ‐‐‐ >>On Wednesday, November 13, 2019 8:42 PM, Edward Finnell >><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: >> >>> Is there a DSS function to list the contents of the backup? We were FDR and >>> it was straight forward. >>> >>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, >>> retired-mainfra...@q.com writes: >>> The error has nothing to do with labels. DFDSS processed 32 blocks of data >>> and reported a problem when reading the 33rd. >>> >>> - >>> >>> >>> 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 > > >-- >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: DFDSS backup retore
just now read Retired's post Carmen Vitullo - Original Message - From: "Carmen Vitullo" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 14, 2019 6:55:35 AM Subject: Re: DFDSS backup retore norun will only syntax check your parms, control cards, are you using the catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? Carmen Vitullo - Original Message - From: "Dean Nai" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 14, 2019 6:48:48 AM Subject: Re: DFDSS backup retore Hi Mark, Ran the job with the NORUN part and it got a RC=0. Not sure what that proved but maybe something. I then dumped the tape label and it looks good although as we know it only shows the last 17 characters. I used one of the other tapes that had the same error for the tape label dump. L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MODE RESTORE - ADMIN - INDDNAME(INDD1) OUTDDNAME(OUTDD1) - FULL COPYVOLID PURGE ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS Dean Nai On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark Jacobs" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. > >Mark Jacobs > > >Sent from ProtonMail, Swiss-based encrypted email. > >GPG Public Key - >https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$ > > >‐‐‐ Original Message ‐‐‐ >On Wednesday, November 13, 2019 8:42 PM, Edward Finnell ><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > >> Is there a DSS function to list the contents of the backup? We were FDR and >> it was straight forward. >> >> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, >> retired-mainfra...@q.com writes: >> The error has nothing to do with labels. DFDSS processed 32 blocks of data >> and reported a problem when reading the 33rd. >> >> - >> >> >> 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 -- 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: DFDSS backup retore
norun will only syntax check your parms, control cards, are you using the catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? Carmen Vitullo - Original Message - From: "Dean Nai" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 14, 2019 6:48:48 AM Subject: Re: DFDSS backup retore Hi Mark, Ran the job with the NORUN part and it got a RC=0. Not sure what that proved but maybe something. I then dumped the tape label and it looks good although as we know it only shows the last 17 characters. I used one of the other tapes that had the same error for the tape label dump. L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MODE RESTORE - ADMIN - INDDNAME(INDD1) OUTDDNAME(OUTDD1) - FULL COPYVOLID PURGE ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS Dean Nai On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark Jacobs" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. > >Mark Jacobs > > >Sent from ProtonMail, Swiss-based encrypted email. > >GPG Public Key - >https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$ > > >‐‐‐ Original Message ‐‐‐ >On Wednesday, November 13, 2019 8:42 PM, Edward Finnell ><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > >> Is there a DSS function to list the contents of the backup? We were FDR and >> it was straight forward. >> >> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, >> retired-mainfra...@q.com writes: >> The error has nothing to do with labels. DFDSS processed 32 blocks of data >> and reported a problem when reading the 33rd. >> >> - >> >> >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS backup retore
Hi Mark, Ran the job with the NORUN part and it got a RC=0. Not sure what that proved but maybe something. I then dumped the tape label and it looks good although as we know it only shows the last 17 characters. I used one of the other tapes that had the same error for the tape label dump. L.SMFLGB.G0303V00 19.287 99.000 U25458 200P 12741274 SYSFBK1W/BACKUP ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MODE RESTORE - ADMIN- INDDNAME(INDD1) OUTDDNAME(OUTDD1) - FULL COPYVOLID PURGE ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS Dean Nai On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark Jacobs" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. > >Mark Jacobs > > >Sent from ProtonMail, Swiss-based encrypted email. > >GPG Public Key - >https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$ > > >‐‐‐ Original Message ‐‐‐ >On Wednesday, November 13, 2019 8:42 PM, Edward Finnell ><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > >> Is there a DSS function to list the contents of the backup? We were FDR and >> it was straight forward. >> >> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, >> retired-mainfra...@q.com writes: >> The error has nothing to do with labels. DFDSS processed 32 blocks of data >> and reported a problem when reading the 33rd. >> >> - >> >> 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: How can I generate a UUID in a z/OS COBOL Program
You can see the Java code implementation here
https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/UUID.java.
On 2019-11-14 3:15 PM, Timothy Sipples wrote:
Frank Swarbrick wrote:
The SWIFT payments network has a field called the UETR
(Unique End-to-end Transaction Reference), which is a
Version 4 UUID. Will the new Enterprise COBOL feature
be able to generate a Version 4 UUID?
You can already generate version 4 UUIDs via INVOKE to a small -- really,
really small -- bit of Java code. Here's a basic Java sample to generate a
version 4 UUID:
import java.util.UUID;
class UUIDSample
{
public static void main(String arg[]) throws
UnsupportedOperationException
{
UUID v4uuid = UUID.randomUUID();
// Then do what you want with v4uuid here
// (Return it, for example)
}
}
SWIFT may or may not need something more than a IETF RFC 4122 version 4
UUID.
This approach works with all z/OS and Enterprise COBOL releases that are
still in service, plus some past releases that have reached End of Service.
java.util.UUID was introduced all the way back in Java 5, for example. (The
Java 5 SDK for z/OS was released on December 16, 2005, and reached End of
Service on September 30, 2013.) I can't remember when INVOKE was first
introduced, but it was a long time ago.
Moreover, if you're concerned about entropy, my understanding with this
code sample is that it'll automatically benefit from the True Random Number
Generator (TRNG) included in the IBM z14 and later processors, just as long
as your Java Runtime Environment is recent enough (which is not
particularly recent at this point) to be aware of the TRNGs. On earlier
models you could presumably ask Crypto Express to provide a TRN to the JRE,
with a few more Java Cryptography Extension (JCE)-related lines of code I
imagine.
In short, while UUID (including UUID version 5) functions in Enterprise
COBOL and/or Language Environment would be most welcome in my view, you
don't have to wait, and you shouldn't wait. Solve the problem you have, and
it's very easy to solve, right now.
If somebody wants to raise an objection such as "Oh, I can't do that --
that's another language," then my basic response is "Don't be silly." JCL,
DL/I, and SQL are also languages that aren't COBOL, and so what? A COBOL
programmer would hardly be a competent one without knowing a little bit
about some other languages, enough to be useful and productive anyway. Two
of those three aren't included in the base z/OS operating system, as it
happens, but Java is. Did the English language wait to arrive at some
consensus alternative instantiations of the words sushi, taxi, and detente,
as examples? INVOKE is there for a reason (and has been for well over a
decade), so use it!
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com
--
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: JES NOTIFY EMAIL=
So, I wanted to circle back around on this topic. I just saw the Share presentation slides for session 25309 "What's new in z/OSMF in V2.4". I've got V2.4 Serverpac installed, just not IPLed anywhere yet, but looking at the slides I predict that IBM has hit this one out of the ball park! Besides all the new features, there is a Security Configuration Assistant that appears to really dissect the required security setup, as well as provide diagnostics process on what needs to be done. https://share.confex.com/share/133/webprogrameval/Session25309.html I look forward to taking a new look at this. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, November 11, 2019 8:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES NOTIFY EMAIL= **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** thanks for your insight Brian, I'll have to check my security once, more, I would hope IBM support would have seen the security issues back in August when I opened the PMR and received the first trace as I said before they assured my my security was setup correctly Carmen Vitullo - Original Message - From: "Brian Westerman" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Saturday, November 9, 2019 4:27:48 PM Subject: Re: JES NOTIFY EMAIL= On Fri, 8 Nov 2019 09:35:43 -0600, Carmen Vitullo wrote: >David I feel your pain, we are also a TSS shop, CA (BROADCOM) has some good >doc on converting RACF to TSS, if you need I'll see if I can get the link to >you. > >my previous reply to Brian never was posted, > >agree, and what I do not understand, is the freebee software like JES2MAIL and >other paid products work well, access our SMTP passthru server with no issues, >this is not just a JES2EDS issue, but a normal notification issue from z/OSMF, >I can sent email's from OPS, from JCL batch, no issues, using the same >configuration, I'm trying to get ahead of the game and setup all the parts >pieces for z/OSMF, I suspect the notification, once we're are forced to us >this POC, will be very important. >another trace yesterday sent to level 2, SEV2 ticket still open since Aug 27th >:( > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Yes, the problem with the new JES mail option isn't getting CSSMTP to work with it, you will likely find that you missed one of the install steps or misinterpreted the results like I did (3 times). I ended up going through the entire install 4 times before I got it "right" thinking that everything was fine each time and it turned out that while the steps all seemed to have worked, checking the content of the issued messages themselves pointed to the problem I had with the izudflt.zosmf.notification.notify part. It turned out that no one (except zosmf itself) was authorized to send the email. :( But even when it was done and completely implemented, it wasn't even as nice as the stuff you can get off the freeware tapes. It is a particular pain to have to actually add the notify card to the jobs. I think there are several better ways that it could have been handled and it could have been much more comprehensively implemented. While it doesn't "suck" per se, it's not really worth the enormous effort for such a small "feature". If you already are running z/OSMF, then adding it is not going to really be a big deal, but I don't see any part of it which is worth the effort to implement (and actually run since z/OSMF is installed for you at serverpak now), all of z/OSMF just to get the notify part. I just keep falling back to the fact that if you don't make something simple and easy to use, that most people just won't bother to use it, at least not when it counts. We made SyzMPF/z and SyzMAIL/z so that normal installation is on the order of 10 minutes or less. I can't imagine what they were thinking when they decided to design the notify feature of z/OSMF but I'm thinking that it wasn't ease of implementation or use. :) Brian Westerman Syzygy Incorporated https://protect2.fireeye.com/url?k=ec44547c-b018a073-ec447ee4-0cc47a33347c-11d4d09cb136ba57=http://www.syzygyinc.com/ -- 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
Re: Tracking called (non-main) programs using SMF records
Hi, as other colleagues already said, no standard SMF way. At my customers sites, they use TADz (it seems Ptracker gives more information like the chain between caller and called) and for some of them a product we developed to correlate CICS-Transactions with LINKed/CALLed programs (written to SMF records). About cleanup, if applicable, keep attention to static linked programs who seem to be called by nobody. Best regards. Max Il giorno mer 13 nov 2019 alle ore 17:07 Steff Gladstone < steff.gladst...@gmail.com> ha scritto: > We would like to clean up our load libraries by deleting unused programs. > > Is there any way to use SMF data to track real-time usage of programs which > are not main programs but are called by other programs? > > We were under the impression that only executions of main programs (PGM=) > were recorded with SMF. Scanning program sources for called programs is > unsatisfactory for us since the call could be dynamic (name of program > contained in a variable) or conditional on a particular set of > circumstances that never occurs in practice. > > Thanks in advance! > > Steff Gladstone > > -- > 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
