Hi John, On a couple of occasions over the years, I’ve considered diagramming batch workloads as well. I never ended up implementing anything, but the following is what I was leaning towards…
Inputs: raw JCL (proclibs, joblibs, etc.), processed JCL (joblogs, JOEs, etc.), maybe some externalized scheduler data, etc. ProcessA: create rexx exec(s) or C/C++ programs to read and parse all inputs and create some internal representation of the workload to be diagrammed. The internal representation is then passed and relational database objects representing a workload ‘uow’ (job or jobstep or whatever) are created from it. The internal representation might contain jobname, step/procstepname, startstop times, various descriptions, dependencies, etc.. ProcessB: the relational objects created by ProcessA are extracted by a database modeling tool which reverse engineers the physical schema (it connects to a LUW or z/OS DB and extracts whatever you've pointed it at), the modeling tool then generates a diagram of the relational objects that should represent your workload. At this point the modeling tool could be used to adjust the diagram as desired, but if you want to automate, that would probably be better handled at object create time. The names of the objects created would be based on whatever you’re interested in diagramming. You might have a table correspond to a single jobname, and its columns represent the steps/procsteps within the job. RI constraint names could be used to represent the dependencies between jobs. If you used DB2 on Z or LUW, most of the object names can be up to 128 characters long, providing quite a bit of flexibility for their usage. In addition, tables and columns both have comment fields associated with them which might be used to contain the description of jobstep, assuming there are some standards in place for production JCL. I think there’s a lot of possibilities here. You are basically ‘redefining’ peices of the relational model to handle your diagramming needs. UML might be another option for you, with structures that better lend themselves to workload diagramming (not sure, but could be worth looking at) For example, if you were diagramming a banking workload that handled DDA Stop-payments, your rexx exec might have created a table with the name - ‘DDASTOPD Reconciles DDA Stops from domestic partners’, where ‘DDASTOPD’ is the first part of the table name taken from a jobname, and ‘ Reconcile DDA…’ might be the remainder of the table name take from a job summary in the JCL or scheduler data. Similarly, a column name might be composed of a jobstep name, program name, parm input, etc.. I don’t believe there’s any reason to ever populate any of the objects created with data. They are basically just a subset of workload inputs and artifacts used to represent that workload in diagram form. They probably don’t need to persist. I don’t know of any freeware relational DB modeling tool that provides the reverse-engineering capability needed to produce a diagram, but nor have I looked. I’ve used both PowerDesigner which is very option rich but unfortunately from MS, and Erwin which is unfortunately a CA tool. I’m pretty sure PowerDesigner is much more reasonably priced. You might also be able to do something similar via UML, in which case tools might even be available at no charge. I am pretty confident the above could be fully automated (I know it could using PD, because it has some built-in automation and scripting capabilities) Much of the above assumes some database admin and or data modeling tool experience. If neither of these are available, then the above may have too steep a learning curve to be cost-effective. Hope this helps, Mike Hochee ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
