Pages

Showing posts with label mvs. Show all posts
Showing posts with label mvs. Show all posts

Wednesday, April 25, 2018

Auditing RACF Using Microsoft Access or any SQL Database

Executive Summary

Aside from being difficult, auditing RACF requires special skills. It needs understanding of RACF concepts plus understanding of the other subsystems being audited. A comprehensive manual audit took four auditors two months to complete. This can make the audit report irrelevant by the time it is released because errors may have been corrected already - making the auditors look incompetent - or worse, security breach may have occurred without the auditors detecting it.

Thursday, May 13, 2010

MVS Link Editing

As mainframe programmers know, link editing is one of the most tricky part in creating an executable program. Compiling is easy. Choose the right compiler for your source, input your source and you have an object code.

Monday, July 20, 2009

Mainframe Programmers: Where are they?

One of the difficulties in working on a mainframe environment is looking for good people. A lot of those who know mainframes are retiring or have retired and are living on their boat. For a lot of those in university, mention the word mainframe and they will run away as if the mainframe is a plague that should be avoided.

Monday, June 15, 2009

Mainframes: Are they Boring?

I started my career as an operations analyst for MVS. I later moved on to be a systems programmer for MVS and IMS. This was and still is the best part of my career.

I had since graduated from MVS to pursue other areas of IT. The past few years brought me back to the mainframe. I was really surprised to see a lot of improvements on MVS. You can use it to deliver web services. You can connect it to any web application, access DB2 and IMS from a web application.

I left MVS when MVS/XP was coming out. I was not able to play with 31 bit addressing.

In the past several years, things have changed. Real storage is now in Gigabytes, whereas before, 16 MB was the highest an application can go - and that was in virtual storage!

You now have FTP, SFTP and FTPS as transport protocols.

There's also OMVS which allows you to use *NIX services on MVS!

The application architecture has changed also. There are now technologies that allow you to wrap existing IMS and CICS transactions into web services that can be served to web clients. You can call API's that allow your MVS COBOL code to access web services outside of MVS. There are also technologies that allow you to access your hierarchical IMS databases via SQL. And lastly, you can present your dull green screens as a web page.

One thing that I realize is these new buzzwords: like virtualization, XML, even the concept of paging, all these have their origins on the mainframe.

IBM allowed virtual machines through their VM product. With XML, data is presented hierarchically - and IMS started this concept. IMS is a lot more powerful though. The concept of separating data from presentation also has its origin from the mainframe. With MFS, IMS programs did not need to concern themselves with how the data is presented. The presentation is coded in MFS.

Lastly, paging - OS/VS1 had this. That was what VS stood for - Virtual Storage meaning it provided more memory than what it really had. The advantage of how the mainframe implemented VS is the way VS is handled. For Windows and *Nix systems, VS is one big block of memory shared by all the tasks. on the Mainframe, each address space has the same amount of virtual storage. So for 31 bit addressing, each address space has 1GB of virtual memory. It does share some overhead with the system but from its perspective, it has the whole 1GB to itself. Of course, when you have 64bit addressing, the available virtual storage is a lot more.

Now who says mainframe technology is dying and boring?

Total Pageviews