370 Assembler Object Code Translator:
Starting with the fun! For no apparent reason I decided to build a self-evaluating "Object Code Translator". Originally written in 370 Assembler/CICS on the mainframe (Aug'1991) then converted to PC/370 Emulation on Windows 95 (Oct'1996). I ran this on Windows 10 using DOSBox to produce the screenshot below - still works like a charm! Starting at offset zero (x'0000') it evaluates the object code in memory & deciphers the instructions (format, mnemonic & operands). Pressing the function keys allow you to traverse through the load module - one instruction at a time, line by line or stepping through 50 instructions. The actual code to produce this is very tight, yet organized so it's easy to understand & modify if additional features are needed. More on this later.
Configuring WinBatch as an Executable PeopleSoft Process Type:
More fun. PeopleSoft is configured to run process types like SQR, Application Engine, COBOL, Crystal Reports, BI Publisher, etc... but I decided to add a new one to fulfill a business requirement (integrated with MS Excel). WinBatch is a robust windows based scripting language that can be compiled & executed. Perfect for this situation & many more. I created a WinBatch PeopleSoft adapter that connects & executes just as smoothly as the delivered process types. My custom package contains the primary Adapter Module (FTPSWBT) along with functions for Command Line Argument Parsing (FTPSARG), Oracle Connectivity/SQL (FTPSORA), Process Scheduler Integration (FTPSAPI) & Log File Support (FTPSLOG). Below is a random snippet from the FTPSAPI.WBC Process Scheduler Update.
Through the Adapter API, WinBatch was utilized as an effective Windows/NT PeopleSoft Tool. Below is the Log File for a WinBatch Process FTAPLOAD which reads Excel Spreadsheets & Loads them into the PeopleSoft Database for processing. Complete seamless integration with PeopleSoft.
PeopleSoft EPM Custom Data Mart Builder Innovation:
PeopleSoft EPM (Enterprise Performance Management) is an application that manages your Data Warehouse & reporting Datamarts. To be brief, the delivered Datamart Builder component (circa 2004) consists of numerous layers of extraneous Application Engine programs that align with a static Source Map of SQL Objects that aren't utilized properly - they are redundant placeholders. When faced with a complex datamart implementation for a client I decided to scrap the "conventional methodology" & take a more innovative & effective approach. I expanded the Source Type Meta-Data set to include a more robust set of functions & controls. I built a primary Datamart A/E Module (completely integrated with EPM security, run controls, activation, etc) to build all Dimensions/Facts using the new Source Mapping which includes conditional logic & Incremental/Destructive Load options among many other useful amenities. A web of A/E programs was avoided with more flexibility attained. Below is a screenshot of a portion of the Account Dimension:
Below is the custom Application Engine Module (ZDM_SRC) I wrote to handle the various Source Types. Of course, this is only a high-level view...
This concludes my Introductory Post... more to follow.
