#17 – PI’s and DPK’s (Part 2)

Hey great podcast. So many things I’ve dealt with, CORS Web Profile setting in 8.54, Cobol, etc.. Had to deal with CORS for a Shibboleth front end. As for your own custom web profile properties. These can be used in your “look and feel” signin.html, siginout.html, pages. We used it for a maintenance window notice to users on login page. You can use it like other “bind” variables. It allowed the maintenance time to be configured in web profile:

function inMaintenanceWindow() { 
  var currentDate = new Date(); 
  var currentDayofWeek = currentDate.getDay(); 
  var currentHour = currentDate.getHours(); 
  var currentMinute = currentDate.getMinutes();       

  // Config for Maintenance window - defined in web profile
  var startDay = parseInt('<%=maintStartDay%>') || 0;
  var startHour = parseInt('<%=maintStartHr%>') || 0;
  var startMinute = parseInt('<%=maintStartMin%>') || 0;

  var endDay = parseInt('<%=maintStartDay%>') || 0;
  var endHour = parseInt('<%=maintEndHr%>') || 0;
  var endMinute = parseInt('<%=mainEndMin%>') || 0;
} 

We also built our own custom cobol compiler script (Linux) that spoofs a “HOME” environment variable that achieved the same result as you noted having all compiled results in cust home. Since we started the script, we added INAS stuff and run the store.dms automatically, and let our migrators run it through STAT. Saves a lot of my admin time.

My 2 cents, DPK is good for PUM (though so were the past scripts), but for real world, it was useless for us. We started to use ansible to automate Peoplesoft, then discovered the Puppet DPK, and found it disappointing, complex, and limited flexibility to our architecture. Considering the standalone use of Puppet, and the user audience, I’m a bit surprised they didn’t use ansible. I found it more useful for application deployment and more flexible to add custom architecture configs (which we have a lot of).