Toggle Sidebar
  • Recent updates
    • Post is under moderation
      Ron Palaniuk
      Resolve issues with installing ChangeMan ZMF packages that end-up having Audit out-of-synch situations because time has passed. This particular issue has been around for a couple of decades, and we sh...ould look at resolving the issue to get around this particular “hole” in the ChangeMan ZMF software lifecycle. Here is the scenario: You have a ChangeMan ZMF Package 1 that has Component A that was changed as part of a long-running project.  Package 1 was Audited successfully and Frozen, and then goes to, say, INTG testing for several weeks.  No additional changes end-up getting done to anything within Package 1, hence no reason for any additional Audits of Package 1. While INTG testing is being done of Component A, a production maintenance change needs to be done to Component A.  So Package 2 is created.  Component A has the minor change done, and for whatever reason the developer does not notify the owner of Package 1 of this maintenance change. Then Package 2 is Audited successfully, Frozen, and Installed into production within a day or two. The owner of Package 1 would have had a “checkout conflict” TSO message flash by on his/her screen, but (s)he would have likely missed it when you end-up pressing function and/or the Enter keys in quick succession. When the owner of Package 1 installs the project’s change into production, then the change from Package 2 gets accidentally regressed in production. Granted, we can implement (and have suggested implementing) a manual processes so that the final approver (or close to the final approver) has to submit a package Audit to ensure that there are no last-minute Audit errors.  However, anything that is manually done can be forgotten and missed. With regard to a design to get around this issue in ChangeMan ZMF, we are flexible.  But here is an idea: Maybe R&D can implement a Last Package Audit Date/Timestamp field that is stored as part of the ChangeMan ZMF package metadata.  Within Global Admin (which can be overridden in Application Admin), one can specify (1) which approval level number(s) must have a Package Audit be run before an approval can be done, and (2) how old the Last Package Audit Date/Timestamp can be until another Package Audit has to be run before the next approval level associated with a Package Audit requirement can be done.  If nothing is specified in one or both of these new configuration items in admin, then ChangeMan ZMF would act just like it has been with the scenario described above.  (As an aside, I suppose that this age-based requirement for Package Audit can also be applied to packages that are in DEV status that were Audited, say, 2 months ago.  In this situation, it is possible to freeze a package in DEV status with an Audit RC=00 from 2 months ago that now has a version regression situation that could go undetected.) The reason to have the ability to specify one or more approval levels that are associated with a Package Audit requirement is to take into consideration situations when a package may be in FRZ status while in QUAL and then INTG testing.  Testing could go on for months, and things can change in just a few days (if not hours).  If, for example, there was a Package Audit requirement prior to giving approval to promote to QUAL, and also an Package Audit requirement prior to giving approval to promote to INTG, and then finally a Package Audit requirement prior to giving approval to install into PROD, then one could avoid out-of-sync conditions earlier in the testing part of software lifecycle, and even eliminate them before going to PROD---even if the package stays in FRZ status (without any changes via selective unfreeze) for several months. As far as being able to quickly “eyeball” which ChangeMan ZMF packages’ Audit RCs are too old (or “expired”), maybe within the CMNLIST3 panel the “Aud” field could have a different color (e.g. red) indicating that the Audit RC has expired and a Package Audit needs to be re-run.  Of course, any package in BAS status would not have a different color, even after the age-based Package Audit criteria has expired. It was mentioned to associate an approval level number with a Package Audit requirement.  Thinking about it more, it may make more sense to associate the Package Audit requirement with an approval security entity. I do realize that the above idea still does not resolve the situation in which a package has had all its approvals done, and the package sits in APR or DIS status for days, weeks, or even months before production installation.  By then, something could have changed that would result in a package out-of-synch situation as far as Audit would be concerned.  I’m not sure what we could do to get around this, but at least being able to “eyeball” which ChangeMan ZMF packages’ Audit RCs have expired that are in a different color (such as red) within the CMNLIST3 panel would be helpful.  I suppose that something can be implemented where if anyone tries to reference the package through option U1, S2, BB, QP, etc., then a “PACKAGE AUDIT EXPIRED” ISPF message could be displayed as a warning.  This particular message would definitely show-up for packages in APR or DIS status, and maybe a Global and Application Admin setting can be created that would also show this message for packages in other non-BAS statuses (which I can see some users complaining about getting that message quite often...but for a critical application, this might be acceptable). More
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk added new listing Create “Unlock Component” Security Entity Check in ChangeMan ZMF/Mainframe
      Create “Unlock Component” security entity check As of ChangeMan ZMF version 8.1.0.01, the only people that can unlock a component is either the person that locked the component or a ChangeMan ZMF Glob...al Administrator. In our team, we have people that do more of the “day-to-day” activities that help-out our ChangeMan ZMF users and we also have people that are experienced ChangeMan ZMF administrators. All people on our team sometimes need to unlock components within a ChangeMan ZMF package; however, some people on our team are not yet educated to do ChangeMan ZMF administration. Thus, we had changed their Global and Application Admin access to READ instead of UPDATE. However, not surprisingly, we had found that they had lost their ability to unlock components for other people because of this access change to READ. It would seem appropriate that a new security entity check be created called “Unlock Components Entity Check” within Application Admin, much like the existing (and relatively new) “CMNAUDRC Entity Check”. This way, we can give certain people (or all people, for that matter) the ability to unlock components that were locked by someone else, and not have to give them UPDATE access to Global Admin. From a security point of view, this would be far more desirable. I suppose that, as a default, if the new “Unlock Components Entity Check” would have no value specified, then it would have the previous behavior and default to only allowing a ChangeMan ZMF Global Administrator with UPDATE access to be able to unlock components. This way, this new feature would not affect current customers that expect the old behavior of who can unlock components. However, any shops that want to take advantage of this new feature would be able to when they are ready. More
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk added new listing Create “Unlock Component” Security Entity Check in ChangeMan ZMF/Mainframe
      Create “Unlock Component” Security Entity Check As of ChangeMan ZMF version 8.1.0.01, the only people that can unlock a component is either the person that locked the component or a ChangeMan ZMF Glob...al Administrator. In our team, we have people that do more of the “day-to-day” activities that help-out our ChangeMan ZMF users and we also have people that are experienced ChangeMan ZMF administrators. All people on our team sometimes need to unlock components within a ChangeMan ZMF package; however, some people on our team are not yet educated to do ChangeMan ZMF administration. Thus, we had changed their Global and Application Admin access to READ instead of UPDATE. However, not surprisingly, we had found that they had lost their ability to unlock components for other people because of this access change to READ. It would seem appropriate that a new security entity check be created called “Unlock Components Entity Check” within Application Admin, much like the existing (and relatively new) “CMNAUDRC Entity Check”. This way, we can give certain people (or all people, for that matter) the ability to unlock components that were locked by someone else, and not have to give them UPDATE access to Global Admin. From a security point of view, this would be far more desirable. I suppose that, as a default, if the new “Unlock Components Entity Check” would have no value specified, then it would have the previous behavior and default to only allowing a ChangeMan ZMF Global Administrator with UPDATE access to be able to unlock components. This way, this new feature would not affect current customers that expect the old behavior of who can unlock components. However, any shops that want to take advantage of this new feature would be able to when they are ready. More
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Right now, it appears that when CMNHUTIL runs and tries to access a directory (such as root "/") that it does not have access to, it results in a S0C1 abend within CMNHUTIL with OFFSET=000010E6 within... ChangeMan ZMF 7.1.1.02. This particular error, in reality, does not tell a customer much about what the problem is. I ended-up inferring that this is a problem because I happened to see that the FILEOUT= was trying to write a shell script to the root (/) directory: //WRJ2TMP EXEC PGM=CMNHUTIL, create shell command ... //SYSIN DD DATA,DLM='++' ... FILEOUT=/D67hg9r0ua6.sh ... ++ It would be helpful if certain common errors that could happen within CMNHUTIL be given in the job output to aid with better and quicker troubleshooting. The above situation would be some kind of security violation message. I'm sure that there are other situations, which currently result in an abend, that that could be coded into CMNHUTIL to give a readable error message. More
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk updated their profile picture
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk joined the group ZMF User Defined Impact Analysis SIG
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk joined the group ZMF and ADABAS/Natural SIG
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      DevOps Interchange16 Attendee
      Attended the 2016 DevOps Interchange in Chicago
      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Ron Palaniuk
      Ron Palaniuk is reading the article Community.

      Community

      posted in Uncategorised on 3rd Apr, 2015

      Stream item published successfully. Item will now be visible on your stream.
    • Post is under moderation
      Within the ChangeMan ZMF Administrators Guide, there is an “Enabling the Network Data Mover” section that discusses taking a copy of the #NDM member from the CMNZMF CNTL file, and then following a few... steps. In this enhancement request, I’m proposing that we streamline this process a bit. It appears that we have an opportunity to make a ChangeMan ZMF upgrade (or even an installation) a little more seamless when it comes to ChangeMan ZMF systems configured to use NDM (Connect:Direct). Instead of putting a copy of the #NDM member into the custom CMNZMF CNTL library, changing the “$/” to “./”, and specifying the correct “DSN=somnode.NDMPLIB” (i.e. &NDMPLIB) library before running the JCL that uses PGM=IEBUPDTE, why not have the NDM PROCESS members be built within the ChangeMan ZMF skeleton? The way I see it, the #NDM member needs to be run to add NDM PROCESS members against each node that NDM (Connect:Direct) will be running in. This means that multiple ‘somnode.NDMPLIB’ (i.e. &NDMPLIB) libraries would need to be updated in various places. In a multi-LPAR shop, this can be a fair bit of effort—especially being that a ChangeMan ZMF administrator may not have access to update ‘somnode.NDMPLIB’ libraries and would need to coordinate with another group, such as System Programming. Also, during a ChangeMan ZMF upgrade, if any of the NDM PROCESS members (e.g. CMNSUB and CMNNDM) were to be changed by Serena R&D as part of an upgrade, then the ChangeMan ZMF administrator needs to remember to change the NDM PROCESS members in the various ‘somnode.NDMPLIB’ libraries. Additionally, consideration needs to be done in that a current production version of ChangeMan ZMF may need to still be using the old version of, say, the CMNSUB NDM PROCESS, but the new upgraded ChangeMan ZMF test version may need to be using the new version of the CMNSUB PROCESS. How does one ensure that a given ChangeMan ZMF subsystem is using the current version of the CMNSUB NDM PROCESS when there is only one ‘somnode.NDMPLIB’ per NDM node that can be used for all (test and production) ChangeMan ZMF subsystems? Additionally, the #NDM member currently creates the following NDM PROCESS members: • CMNSUB • CMNNDM • COPY • RUNJOB I did a search against the various skeletons, and the only NDM PROCESS members that are used are: • CMNSUB • CMNNDM It appears that we don’t need the following ones anymore: • COPY • RUNJOB Based on my analysis, the only place that we will need to build the NDM PROCESS members on-the-fly is within the CMN$$PND skeleton. What I’m proposing is to modify the delivered CMN$$PND skeleton from ZMF 8.1.0.00 as follows: *********************************************************** Top of Data ******************************************************* S E R C M P A R (MVS - 862 - 20110512) 2 TEXTONLY THURSDAY JULY 23, 2015 (2015/204) 17:45:31 PAGE 1 SYSUT1=STD50.CHG.A019C.#CF4A217.#31D3497.SSV,SYSUT2=STD50.CHG.A0097.#CF4A217.#30B0717.STG //*)IM CMN$$PND O N E 1 )CM O N E 2 )CM ROUTINE TO EXECUTE CONNECT:DIRECT DATA TRANSMISSION VEHICLE O N E 3 )CM AT A REMOTE SITE. O N E 4 )CM O N E 5 )CM SIGNON LIBRARY SHOULD CONTAIN: "SIGNON USERID(USERID)" O N E 6 )CM O N E 7 )CM This file should be protected so that only ChangeMan ZMF and other O N E 8 )CM authorized tsoids are permitted access. O N E 9 )CM O N E 10 ++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++ I //NDMPRCLB EXEC PGM=IEBUPDTE, *** CREATE CONNECT:DIRECT PROCLIB DIF T W O 11 + I // PARM=NEW DIF T W O 12 + I //SYSPRINT DD SYSOUT=* DIF T W O 13 + I //SYSUT2 DD DISP=(,PASS),DSN=&&&&NDMPLIB, DIF T W O 14 + I // UNIT=SYSDA,SPACE=(TRK,(1,1,20),RLSE), DIF T W O 15 + I // DCB=(DSORG=PO,RECFM=FB,LRECL=80,BLKSIZE=0) DIF T W O 16 + I //SYSIN DD * DIF T W O 17 + I ./ ADD SEQFLD=801,NAME=CMNSUB DIF T W O 18 + I CMNSUB PROCESS DIF T W O 19 + I RUN JOB (DSN=&&DSN) - DIF T W O 20 + I &&SRC DIF T W O 21 + I ./ ADD SEQFLD=801,NAME=CMNNDM DIF T W O 22 + I CMNNDM PROCESS DIF T W O 23 + I CPYPKG COPY FROM(PNODE DSN=&&PDSN1, - DIF T W O 24 + I DISP=SHR) - DIF T W O 25 + I TO (SNODE DSN=&&SDSN1, - DIF T W O 26 + I DISP=(RPL,CATLG)) - DIF T W O 27 + I COMPRESS PRIME=X'40' DIF T W O 28 + I RUNDST IF (CPYPKG = 0) THEN DIF T W O 29 + I RUN JOB (DSN=&&DSN) - DIF T W O 30 + I &&SRC DIF T W O 31 + I EIF DIF T W O 32 + I /* DIF T W O 33 + ++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++ //DMBATCH EXEC PGM=DMBATCH, *** TRANSFER DATA VIA CONNECT:DIRECT O N E 11 // PARM=(NNNNNNN) O N E 12 ++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++ D //DMPUBLIB DD DISP=SHR,DSN=&NDMPLIB DIF O N E 13 + --------|---.----1----.----2----.----3----.----4----.----5----.----6----.----7----.----8--------------------- I //DMPUBLIB DD DISP=(OLD,DELETE),DSN=&&&&NDMPLIB DIF T W O 36 + I // DD DISP=SHR,DSN=&NDMPLIB DIF T W O 37 + ++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++ //DMMSGFIL DD DISP=SHR,DSN=&RNDMMID O N E 14 //DMPRINT DD SYSOUT=* O N E 15 //NDMCMDS DD SYSOUT=* O N E 16 //SYSUDUMP DD SYSOUT=* O N E 17 //SYSPRINT DD SYSOUT=* O N E 18 //SYSIN DD DISP=SHR,DSN=&NDMSGNO O N E 19 // DD * O N E 20 NETMAP=&RNDMMAP,ESF=YES O N E 21 S E R C M P A R (MVS - 862 - 20110512) 2 TEXTONLY THURSDAY JULY 23, 2015 (2015/204) 17:45:31 PAGE 2 SYSUT1=STD50.CHG.A019C.#CF4A217.#31D3497.SSV,SYSUT2=STD50.CHG.A0097.#CF4A217.#30B0717.STG SER71I - END OF TEXT ON FILE SYSUT1 SER72I - END OF TEXT ON FILE SYSUT2 SER75I - RECORDS PROCESSED: SYSUT1(21)/SYSUT2(45),DIFFERENCES(0,0,24) EXPLANATION - 0 RECORDS DIFFER THAT SYNCHRONIZED TOGETHER 0 RECORDS WERE CONSIDERED INSERTED ON SYSUT1 24 RECORDS WERE CONSIDERED INSERTED ON SYSUT2 SER80I - TIME OF DAY AT END OF JOB: 17:45:31 - CONDITION CODE ON EXIT: 4 ********************************************************** Bottom of Data ***************************************************** Honestly, I’m not even sure we need to have the following, since ChangeMan ZMF out-of-the-box does not call any NDM PROCESS members sitting within the NDM process library, &NDMPLIB: //DMPUBLIB DD DISP=(OLD,DELETE),DSN=&&&&NDMPLIB // DD DISP=SHR,DSN=&NDMPLIB We could get away with just having: //DMPUBLIB DD DISP=(OLD,DELETE),DSN=&&&&NDMPLIB since the required NDM PROCESS members that ChangeMan ZMF needs are stored within &&NDMPLIB that is created via the NDMPRCLB job step. Additionally, the CMN$$NDM skeleton currently does not even reference &NDMPLIB (i.e. ‘somnode.NDMPLIB’) in the DMPUBLIB DD. Even though there is a bit extra overhead in that these NDM PROCESS members need to be generated into the &&NDMPLIB temporary file each time the CMN$$PND skeleton is imbedded, the advantage is that the &NDMPLIB (i.e. “DSN=somnode.NDMPLIB”) does not need to be updated at each NDM node in a coordinated fashion, and you have better support for different versions of the CMNSUB and CMNNDM NDM PROCESS that could occur between different versions of ChangeMan ZMF, since the test ChangeMan ZMF skeleton library concatenation would have the newer version of these NDM PROCESS members vs. the production ChangeMan ZMF skeleton library concatenation. If this enhancement request is accepted, then a few other minor changes need to be done to ensure that the CMNSUBIR process that prevents going over the 255 job step limit does not result in generating a job that has more than 255 job steps. The CMN$$PND skeleton is used as part of the CMNSUBIR’s error handling skeleton of CMNRPMER. The CMNRPMER skeleton imbeds CMNRPMT9. The CMNRPMT9 imbeds CMN$$PND. Because the CMN$$PND skeleton will have an extra job step due to the above proposed change, that means that there is one extra job step would be generated from the CMNRPMER error handling skeleton (specifically when NDM error handling is done; the other transmission vehicles have less job steps for error handling, so having a higher number won’t hurt for the other transmission vehicles). This means that everywhere: )SET SUBERRSK = CMNRPMER is done for the CMNSUBIR skeleton parameter, the: )SET SUBERRJS = 3 needs to be increased by 1. In this case, it would be easiest to consistently change all of the following skeletons: • CMN$$NPM • CMN$$RPM • CMNIMRPM • CMNRPICR • CMNRPMCR that reference the CMNRPMER to have the following set: )SET SUBERRJS = 4 Additionally, within the CMNSUBIR skeleton, the following comment line would need to be updated from: &SUBERRSK &SUBERRJS --------- --------- ... CMNRPMER 3 ... to: &SUBERRSK &SUBERRJS --------- --------- ... CMNRPMER 4 ... I’ve attached a copy of the proposed vendor version of the CMN$$PND skeleton that was modified from the ZMF 8.1.1.00 version. Please take into consideration what should be done with the DMPUBLIB DD concatenation that I had mentioned above, since CMN$$NDM skeleton does not reference &NDMPLIB at all within DMPUBLIB DD. More
      Stream item published successfully. Item will now be visible on your stream.
  • No blogs available.

  • DateTitle
    19/09/2017 Associate User-Selected Package Approval Level(s) with Package Audit Requirement
    20/04/2017 Create “Unlock Component” Security Entity Check
    29/07/2015 ZMF 8.1.0.00 - Include the NDM PROCESS Members in a Skeleton instead of &NDMPLIB
    29/07/2015 Have CMNHUTIL Generate Error Messages instead of Abends

Recent Tweets