SMF records
A general question; from a security and auditing perspective, is there a best practices or recommendation of what SMF records and sub types should be created? //* Peter Ten Eyck //* Senior Systems Programmer //* American National // American National is the brand name for American National Insurance Company, headquartered in Galveston, Texas, and its subsidiaries. Each company has financial responsibility only for its own products and services. American National Insurance Company is not licensed in New York. In New York, business is conducted by New York licensed subsidiaries. For more information, go to www.americannational.com. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF record
What SMF record and report/tool could I use to determine the point of origin for this attempted logon? M 008 ABCD 20180 07:40:36.85 JOB03275 0090 ICH408I USER(RACFID ) GROUP() NAME(??? ) 395 E 395 0090LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED //* Peter Ten Eyck //* Senior Systems Programmer //* American National // American National is the brand name for American National Insurance Company, headquartered in Galveston, Texas, and its subsidiaries. Each company has financial responsibility only for its own products and services. American National Insurance Company is not licensed in New York. In New York, business is conducted by New York licensed subsidiaries. For more information, go to www.americannational.com. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute
Good information, thanks. //* Peter Ten Eyck //* Senior Systems Programmer //* American National // -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barry Lichtenstein Sent: Tuesday, August 20, 2019 3:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute In reply to David and others, a couple of points that might be of interest: * I confirm that the MIGRATABLE attribute is just as people have suggested, to indicate whether a program can be copied between PDS and PDSE, or saved as a load module in a PDS when it was able to be saved as a program object in a PDSE or UNIX. All such operations always requires the binder. * Though there is a bit in the PDS Directory Entry (IHAPDS PDSNMIG), a load module cannot have this attribute. That bit is remapped for a program object, in a load module it is part of PDS2RLDS. Thus you can (for instance) read the directory of a PDSE and still determine if the member is "migratable". A bit is also defined in the PMAR (IEWPMARL PMARL_NMIG). * There is a relationship with the binder COMPAT option, to the extent that the binder has automatically determined the COMPAT level. If the user decides to set COMPAT to some not-required higher level (perhaps to exploit some non-executable feature like binder COMPRESSion), the MIGRATABLE option can still be on. * Besides the two macros, AMBLIST also reports on the MIGRATABLE bit. This is documented in Diagnosis: Tools and Service Aids, that it will print either NON-MIGR or MIGRATE (the explanation of those is no more detailed than the macros). * One of the reasons for setting non-migratable is that the module "text" exceeds 16MB. Binder has elected to not enumerate all the possible reasons. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN American National has changed its email addresses to firstname.lastn...@americannational.com. Please update my email address in your contact list, if applicable, at your earliest convenience. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute
I to struggled to find documentation to answer Dave's question on the MIGRATABLE attribute. Where is the MIGRATABLE attribute documented? I would like to see it... It's not really a COBOL thing right? It's just a flag if a "member" can be copied from PDS to PDSE or perhaps PDSE to PDS? I saw this in the IEBCOPY documentation: "When copying members from a PDSE program library into a PDS, certain restrictions must be considered. Program objects which exceed the limitations of load modules, such as total module size or number of external names, cannot be correctly converted to load module format." //* Peter Ten Eyck //* Senior Systems Programmer //* American National // -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dave Cole Sent: Monday, August 19, 2019 4:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute Thank you Curtis (and the several others who concurred with Curtis). This is what people here were thinking, and certainly it makes good sense. I was hoping to get a definitive link (or response from an IBMer), but this consensus is confirmation enough. Thank You, Dave At 8/19/2019 02:26 PM, Pew, Curtis G wrote: >On Aug 19, 2019, at 12:51 PM, Dave Cole wrote: >> >>1) When a Program Object is MIGRATABLE, what can it be migrated from? >>What can it be migrated to? >My understanding is that a MIGRATABLE Program Object can be copied to a >PDS load library where it becomes a load module. (Program Objects live >in PDSE’s and Unix libraries.) So MIGRATABLE basically means “this >Program Object doesn’t have any attributes that aren’t supported >for load modules.†I haven’t looked deeply enough to say what those >attributes are. >-- >Pew, Curtis G >curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN American National has changed its email addresses to firstname.lastn...@americannational.com. Please update my email address in your contact list, if applicable, at your earliest convenience. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute
Not sure about the COBOL connection... Is the setting of MIGRATABLE attribute by the binder related to binder setting COMPAT= ? I do "think" it indicates the ability to copy PDSE to PDS. //* Peter Ten Eyck //* Senior Systems Programmer //* American National // -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Monday, August 19, 2019 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL]Re: Question about a Program Object's MIGRATABLE attribute Generated by COBOL 5+, as one example. Long names. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4289.htm On Mon, Aug 19, 2019 at 1:26 PM Pew, Curtis G wrote: > > On Aug 19, 2019, at 12:51 PM, Dave Cole wrote: > > > > 1) When a Program Object is MIGRATABLE, what can it be migrated from? What > > can it be migrated to? > > My understanding is that a MIGRATABLE Program Object can be copied to a PDS > load library where it becomes a load module. (Program Objects live in PDSE’s > and Unix libraries.) So MIGRATABLE basically means “this Program Object > doesn’t have any attributes that aren’t supported for load modules.” I > haven’t looked deeply enough to say what those attributes are. > > > -- > Pew, Curtis G > curtis@austin.utexas.edu > > > > > > > -- > 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 American National has changed its email addresses to firstname.lastn...@americannational.com. Please update my email address in your contact list, if applicable, at your earliest convenience. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Reset condition codes?
I wrote this job to convert a bunch of PDSs to PDSEs. I am using variable (ALTERRC) to "reset condition codes" for each invocation of the proc. It works. Is there a better way to do this? Maybe a way I could do something and then use the COND parameter on the COPY step? //PDS2PDSE JOB CLASS=S,MSGCLASS=Q 1007 //* 1109 //* DEFINE SYMBOLS. NEEDED IN ORDER TO USE SYMBOLS IN SYSIN 1207 // EXPORT SYMLIST=(DSNAME1) 1309 // EXPORT SYMLIST=(VOLSER1) 1409 //* 1509 //* PROC TO BE CALLED FOR EACH DATASET TO BE CONVERTED 1609 //CONVERT PROC 1707 //* 1809 //* SET SYMBOLS. NEEDED IN ORDER TO USE SYMBOLS IN SYSIN2109 // SET DSNAME1= 2209 // SET VOLSER1= 2309 //* 2409 //* VARIBLE TO RESET TO 0 FOR EACH INVOCATION OF PROC. 2509 // SET ALTERRC=02609 //* 2709 //* ALTER DSN TO *.OLD NAME 00032809 //ALTEREXEC PGM=IDCAMS 00032909 //SYSPRINT DD SYSOUT=* 00033009 //SYSINDD *,SYMBOLS=JCLONLY 00033109 ALTER -00033209 - 00033309 NEWNAME() 00033409 /* 00033509 //* 00033609 //* CHECK ALTER RC. SET VARIBLE TO RC VALUE OR LEAVE SET TO 0. 00033709 // IF (ALTER.RC > 4) THEN 00033809 // SET ALTERRC=ALTER.RC 00033909 // ENDIF00034009 //* 00034109 //* COPY PDS TO PDSE. ONLY DO IF RENAME WAS SUCCESSFUL. 00034209 // IF ( < 4) THEN 00034309 //COPY EXEC PGM=IEBCOPY 00035009 //SYSPRINT DD SYSOUT=* 0004 //SYSUT1 DD DSNAME=,DISP=SHR00050007 //SYSUT2 DD DSNAME=, 00060007 // LIKE=,UNIT=SYSALLDA, 00070007 // DISP=(NEW,CATLG),DSNTYPE=LIBRARY ,VOL=SER= 00080011 // ENDIF00081009 // PEND 00090007 //* 00090109 //* CALL PROC FOR EACH DATASET 00091007 //STEP01 EXEC CONVERT,N1=FFM.DVLP.LOADLIB,V1=A90362 00093012 . ... more datasets . // 00102109 //* Peter Ten Eyck //* Senior Systems Programmer //* American National // American National has changed its email addresses to firstname.lastn...@americannational.com. Please update my email address in your contact list, if applicable, at your earliest convenience. Confidentiality: This transmission, including any attachments, is solely for the use of the intended recipient(s). This transmission may contain information that is confidential or otherwise protected from disclosure. The use or disclosure of the information contained in this transmission, including any attachments, for any purpose other than that intended by its transmittal is strictly prohibited. Unauthorized interception of this email is a violation of federal criminal law. If you are not an intended recipient of this transmission, please immediately destroy all copies received and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
