JST JCL = Value stream, removing constraints
Job Submit Tool, Test automatization - JCL structuring
Making work of ICT colleagues easier.
Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).
SIAR
S Situation
I Initiatives
A Actions
R Realisations
🔰 lost here, than..
devops sdlc
Progress
- 2020 week:12
- Control line filled.
- Filled with the sprints moments done at some projects over all years.
- The realisation details as counterpart for control is done for testautomation.
- 2020 week:08
There are two story lines,
- What has happened by reorganisations to staff supposed doing tasks.
- Tasks and expectations that were changed doing as technical support.
- 2020 week:12
- The SDLC floor filled with four sub topics.
- Added image map in the control image loops through all control pages.
- Technical detail pages are in the corners.
Contents
Reference | Topic | Squad |
Intro | Making work of ICT colleagues easier. | 01.01 |
Bu line(I) | Learning the Organsisation (I). | 02.01 |
Bu line (II) | Learning the Organsisation (II). | 03.01 |
Initial tasks | Initial Tasks optimised & automated. | 04.01 |
Advanced tasks | Advanced Tasks optimised & automated. | 05.01 |
Results evaluate | Evaluating results - impact value. | 06.00 |
| Words of thank to my former colleagues | 06.02 |
The department syssup (system support) was my landing zone. Other technical departments with direct contacts.
An introduction with persons doesn´t explain everything for expectations and tasks.
System support (SYSSUP) - Mainframe middleware tools
🎭 OS (Operating System) support tasks:
- Maintaining the OS system at supplied versions & fixes. Defining how OS system resources can be protected.
- Tuning the system in line with business usage, coordinated with operations. Changes analyses with performance & tuning.
- "How to" guidelines system usage for the teams: Middleware, DBA, DEV, OPS.
The OS (Operating System) is not the only asset to manage.
A DBMS, filetransfer tool, Analytical tool, programming environment, release management tool, manageble user interfaces to security, printing system, all are examples of middleware.
🎭 Middelware support tasks:
- Maintaining middleware systems at supplied versions & fixes. Defining how middleware system resources can be protected.
- Tuning Middleware in line wiht busienss usage, coordinated with operations. Changes analyses with performance & tuning.
- Setting guidelines how to use mioddleware for DBA, OPS and DEV developers.
DBA Data Base Administration (IDMS)
🎭 DBA the department when to use DBMS resources. Tasks:
- Logical data acess path schema´s "the database") coordinated with developers.
- Phsyical data acess. Changes analyses with performance & tuning of the DBMS.
- Setting guidelines how to code for DEV developers (coding programmers).
DA-DP Data Administration - Data Protection.
🎭 DA-DP (metadata & security) Tasks:
- Defining logical information, structure. Meaning of named elements (metadata).
- In cooperation wiht DBA not allowing DEV to use undefined unclear content.
- In cooperation wiht OPS not allowing access to anybody were needed autorisation is unclear.
- Working together with SYSSUP for technology and tools.
- Alignment with functional business management in any line.
Operations (OPS) - computerroom (OP), planning & support (PB)
🎭 OP (part of OPS) Tasks:
- Having the machines up & running (available).
- All physical movement for tapes (DR backup) and hardcopy prints as deliveries.
- Planned & monitored workload, see PB.
🎭 PB (part of OPS) Tasks:
- Verifying artefacts being delivered are suitablility to use at operations.
- Setting guidelines for DEV in delivered artefacts.
- Planned & monitored workload for business. Interaction with functional managers and OP.
Permanent Test Group
🎭 PTG (part of functional management) Tasks:
- Prepearing and running system en integrations tests.
Interaction with functional managers and PB.
It is key factor in the sdlc (software development life cycle) for reliable predictable code.
The logical placement is far more to functional management and not technology.
The organisation has far more departments than highly specialized technical persons. The department of programmers was in size at least four times bigger.
More departments getting touched when digging into more details.
DEV developers - Cobol IDMS
🎭 DEV Tasks:
- 📚 Detail design of programs, software code with business logic.
- ⚙ Building, realising, coding, the software for the business.
- ⚖ Aligning, adjusting requirements and options for business solutions with SDA and the functional maangers (product owners).
Still part of ICT but organized in business lines. The business context is an important knowledge asset.
🤔 Coding guidelines are set internally and by several ICT lines in several subject contexts.
SDA is doing the the high level abstraction business needs with a high level design.
SDA Business Analysts, Office Automation
🎭 SDA Business Analysts Tasks:
- Analysing business questions and their needs. A Translation between technicians and core business.
- Describing for both worlds the options and what can be expected.
- Helping the decisions makers in what to do.
Recently architects for this kind of role has become popular. The role of code developers technicians into engineers.
Missing in that is the role of what was syssup.
Not everything is necessary to get done in a costly structured way. Self service tools, documenting, planning and administration is better with easy commercial tools.
🎭 Office Automation Tasks:
- Preparing installations and supporting all those easy commercial tools.
- Classic it are desktop based tools, eg the spreadsheet.
Functional management, life insurance policy
Functional management, property insurance policy
Functional management, payments - customers
These are the "heroes" of the core business. There are several business lines and a central one for common services.
For the high level business goals a well cooperation for these business lines would be rational and logical.
There are more interests and concerns than just those mentioned business goals.
No matter what is going one at business lines, the ICT service provision should service them all.
🎭 Functional management Tasks:
- 📚 Detailed information on business logic.
- ⚙ Running monitoring the business only for that part of their responsibility.
- ⚖ Reporting, Communicates, signal with alerts of how well their part as business line is executing.
Actuary, Marketing, Accountancy, bookkeeping
The list of departments with tasks is growing to ones that are bulding op the figures others are relying on:
- 🎭 Actuary on how calculations should be done, what the profit results are in the realisation for the organisation.
- 🎭 Marketing including sales, customer relations. They even code themselves.
- 🎭 Accountancy extracting information from the systems themselves to see whether it is done the way as was documented and promised.
- 🎭 bookkeeping for the financial accountability.
It al started when seeing all the manual work, the long time waiting somebody completed his part of work, the same work being repeated over and over again.
That repetition has historical grown because of it was done in several departments not having thoughts on cooperation.
JCL JOB guidance Form (JBF)
Working on the middelware for changes found myself blocked by some jobs running.
I could not figure out who was running them. At that moment I knew the OPS teams well, so went to them asking what they were.
hat is the moment I got to learn the work of the PTG group.
There were that many PTG persons, but one person of the PB team being busy there. The PTG persons had to fill a hardcopy paper (TRF), using a ot of correction paint.
The PB person used that and making notes on it to create Jobs to run for that group. The throughput limit about 100 jobs a day.
There was another hardcopy paper coming in from the Dev department that described how the programs were supposed to be used with a lot of details on how data was defined (JBF).
When the papers were found to have wrong information the paper had to go back and being corrected before further processing.
There was no business analyst for processes at ICT.
The often used jobs for testers (Pareto)
I got some time and cooperation for doing a little small things.
PTG was willing to do more themselves, the generic data preparation and reporting jobs mainly used for test as test tools too start with.
Interesting discussions started on whether:
- test tools did have a DTAP life cycle or not
- hard coded data in program made it business logic or data
- datasets intended to implement business logic made it not belonging to data
Structuring JCL, a requirement along with operations (JCL2000)
PTG needed more time for acceptance new things, but that other form paper was bothering me.
I found an ear at the PB department to improve that process.
When all jobs would be build in a standard "common job&approach it could be automated.
The question was what the beste and acceptable option for new JCL coding would be.
We made several examples of possiblities doing steps in normalisation.
Showing this to other persons the most structured one was suprisingly acceptable prefered.
Explainging it to another PB person, as soon he did understood the intention, he wanted to start changeing.
We were not ready at that moment.
Of course not everybody did like it, but we could go on.
All kind of batch jobs for testers additional tools (compare)
Running the test by PTG rather well additional questions were asked. Some of those:
- Can we archive (backup) and restore all data, that includes databases and results, for a test plan ourself?
- Can we have some tool to compare the results of several test jobs?
Backup restore tools are coming in wiht the operating system. We delivered them as syssyup to the OPS departmen. Using this tool also at test was not that difficult at that moment.
Comparing data is included in TSO/ISPF the tool could be automated when the data is in datasets.
The backup restore option using a virtual tape and the ADRDSSU backup program got later into discussion.
The problem was that doing a backup of data would be a task only allowed to an operational ICT department (OPS).
The OP (mainframe) department has moved to another location as a result of reorganisation and consolidation. The computer machine was moved out of the building.
The more got automated in the test, operations and development, more functionality was built in.
Education of people being an options in user acceptance testing using the operational code with selected test data.
Technical software changes is a similar way having several versions of the tools middleware on the same machine.
On line Transaction Processing (IDMS)
Implementing the backup restore there is a discrepancy in time.
What has to back uppped validating wit a listing what should have backupped is comparing ouput results in the smae job.
Timing questions are more complicated using a online tranasction system (OLTP).
- the datbase must be restored correctly before the DBMS starts
- When using OLTP and is started, the date has to set (simulated terminal input) and area´s verified to update mode instead of read-only.
- Backup of an database is only reliable when the DBMS has written all data buffers to dasd.
- It has to run under a dedicated service account. (SYSPTG)
- For testing functionality of tranasctions a lot of test accounts conforming roles in production are needed.
Release mangement, parallel testing development (Endevor)
With the DTAP approach home grown tools were present and used for many years.
A huge reorganisation started, a merge of two companies at almost the same size.
With new management in house the promise was made the releasemanagement tool "Endevor" would solve alle test actvities.
Disappointing: release management is not the same as running tests validating archiving test results.
The implentation of Endevor was very complicated wiht a lot of frictions.
Another mismatch that testing should be done in the production systems using the production scheduling without the option in time travelling.
Just think of how monthly and yearly processes should get validated, answer: impossible.
The effect of these mismatches was that the JST tool got rolled out to development (DEV) and to acceptance environments.
Time travelling, unit conversions (Milo Euro)
The period of year 2000 (milo) and euro with the organisational merge dit put a big load on testing. Capacity for testing was never a problem.
For milo an additional tool was installed and used that could manipulate dates in data and the database (EZ-test cogito).
Printing Services, IO guidelines
Printing was in the beginning done in house with an in house placed mainframe. Printers chosen were using Siemens technology.
This technology was already out of date when the machines were moved form the office to another location (early 90´s).
For using the Siemens technology (fob form overlay buffers) the JCL was generated in the header. References to it were made in the IO include-definitions.
When the printer moved from the office an additional overlay for non productional print was added to help preventing test prints would be send out externally.
Technical debt for printing was solved around 2010, allowing the print services to be outsourced. The technology change to the one what was used at other amchines.
Removing bottlenecks, mass processing
The ROI goes positive only hen used intensively.
Imagine:
- Dedicated test-department.
One FTE running all Job manually. 5 FTE doing requests, validations.
Gone into a more variable number of testers, developers working, capacity aligned to the request in throughput of software changes.
- Merging two organisations (1998),
milo (2000) & Euro conversions (2002)
some other major changes.
- Implementing: version / release tool (Endevor)
then needing to roll out for developers (+25).
- Alignment releasing application systems into the end of the SDLC, that is also covering production scheduling.
This is what happened, intensively used from the 1990´s, up to after 2015.
💡 The questions what the tool did had their focus on technical realisations. Far more important was the impact on the workers in the process.
This was not an easy change process, many objections by wanting some other toolset and no dependencies on in house skilled persons.
ISTQB JST-JCL relationship
All work at JST - JCL was done accordingly to the documentation found at ISTQB. ..🤔..
However, it was done years before the ISTQB organization did exist.
Just the mainframe approach is what I have documented here. It is according to the design concepts chapters.
The approach can be used using any tool any environment.
The security association may not that obvious. The DTAP segregation needed to be a logical one because there was only one central machine, the mainframe.
✅ Solving technical questions using naming conventions also made the segrations using the system security more clear.
⚖ Having the overall security and configuration in a way you can run a complete DTAP on a single box (Iron) having containerized anything, is a good practice.
Words of thank to my former colleagues
We had a lot fun in stressfull times working out this on the mainframe in the nineties. The uniquenes and difficulties to port it to somewhere else realising.
A few names:
- 🙏 J.Pak co-designer of the common job approach.
- 🙏 D.Roekel inventing more proc-bodies faster than me.
- 🙏 J.Hofman, P.Grobbee working it out smoothly to testers
Many more people to mention, sorry when I didn´t. (notes: 2008)
Not always unhappy by what is going on
Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).
SIAR
S Situation
I Initiatives
A Actions
R Realisations
🔰 lost here, than..
devops sdlc.
© 2012,2020 J.A.Karman