Re: "Everyone wants to retire mainframes"
Is no-one aware of Master the Mainframe competition for students? https://en.wikipedia.org/wiki/Master_the_Mainframe_Contest And the Academic Initiative, under which the classes mentioned by Wayne are run (Wayne and I worked on these together back in the day): https://www.ibm.com/it-infrastructure/z/education These have been running for more than a decade now and provide a completely cost free access for students to mainframes. In the case of the MtM contest, you don't even really need to be enrolled in an IT related course at a fee paying institute - my 18 year old son can now write COBOL, JCL and REXX after completing last years contest. And in respect of the OP, the 'modernisation' moniker - disclaimer, I also currently work for one of those mainframe modernisation companies. Yes, they do mean replacing your mainframe with x86, and generally they also focus on the C word - Cloud and in many cases some kind of language transposition, i.e. COBOL to Java. Interestingly my employer also sponsored a survey, and while we didn't get the hyped 100% 'want off the platform' result, it does seem there are significant pressures within many companies to see the mainframe replaced or at the very least drastically reduced in cost. The real problem is nothing to do with technology, and all to do with cost. While a single vendor owns the hardware and software stack (think Apple), they can charge whatever they want regardless of the value. There are several technological approaches to the replacement push, some are smarter than others. Like most things in IT, it comes down to factors such as time and money more than technology. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ibm-main@listserv.ua.edu
To try and answer the OP's questions: Support: pretty much on your own wrt IBM, there are forums, and you can get general advice about the z/OS, sub-systems and applications in places like here of course. In any case as it cannot legally be used for real workload, support shouldn't really be so much of an issue. Identical to lpars: sort of, mostly. You can run up a z/VM and host multiple z/OS's or other z/VM's. You can run coupling facility code and simulate a sysplex. You can run Linux for z, either in a z/VM or bare metal. I might be wrong (it's been several years since I had my hands on one), but IIRC they don't simulate the varying CPU types a true System Z can have installed, so no ZIIP/ZAAP or IFL as such. There are several connectivity options, simulated CTC and other types of comms links (not my area of specialisation so I cannot recall the details) so you can have a network of them talking to each other. Security: They run real z/OS, and subsystems - CICS, DB2, WAS, etc etc - so they have RACF (though the ADCD z/OS software bundle supplied with them has a RACF database that is insecurely configured - this has been the case for many years though). Of course the z/OS is hosted as an application running under Linux, so you have to consider the Linux security implications also. It is an easy way to get some workload off the production z/OS box yes. I personally don't think the support overhead is much of an issue - I used one for years and was happy with it, it's stable and just works. Someone else also suggested that it was difficult to put together yourself - I disagree, after upgrading it with every z/OS release for a few years I got very slick and putting together a new one, and would have it built from scratch and all the z/OS stack installed in an afternoon. As has been said before, it's basically IBM's answer (and not a bad answer either) to the alternative emulators that once existed in the market such as MP3000, Flex-ES, PSI or Hercules390 and it's built using a very similar approach and technology. Hoe this helps - cheers, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
maintaining PARMLIBs over several sysplexes
Hi all - it's been a long time since I posted a question here, looking forward to hearing from you all. Question about your local policy/practice: When faced with the task of maintaining multiple PARMLIBS over a few related sysplexes (sandpit, development, production), do you: Prefer to try and keep the contents of each PARMLIB dataset separate, and only containing members that are actually referred to on each specific sysplex, or Prefer to keep all PARMLIB members related to any of the sysplexes synchronised across all the copies of PARMLIB - effectively keeping PARMLIB contents the same, wherever they are found? Some other option? Thanks for taking the time, Regards - Mike Cairns -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fujitsu Mainframe Vs IBM mainframe
The first ten years of my mainframe career I never saw a true IBM installation. First I worked with a Fujistu and MSP, then I moved to a shop that had Amdahl kit, and after that a shop that was Hitachi. At least for the Amdahl and Hitachi the OS was really MVS, OS/390 etc. The Fujitsu environment worked almost exactly the same as the MVS system from the perspective of an applications programmer. The sysprogs probably knew more about the differences than I did at the time. We ran Adabas/Natural, lots of PL/1, SAS, and probably many more besides that I didn't know about (this was my first shop, I was quite young and completely inexperienced of course). Interesting things I remember about the Fujitsu OS: MVS was called MSP - Multiple Systems Product if I recall correctly. But apparently you could see the IBM copyright in the load modules in some places... TSO was called TSS - Time Sharing System RACF was still called RACF - and worked exactly the same Though JCL was the same, we had something called JOL - Job Oriented Language. This was a set of ISPF panels that walked you through creation of each jobstep and built (awful) dynamically allocated JCL. ISPF was called SPF - Systems Productivity Facility We had something called GEM - I forget the acronym, this was a source/version control system if I recall correctly. Used to have to use the TSO SUBMIT and OUTPUT commands a lot - but I guess this was no different from MVSes of the same era (early 80's). We didn't have SDSF. Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fujitsu Mainframe Vs IBM mainframe
One of the funniest things I recall was attempting to understand the documentation. I wish I had kept some of the old manuals just for a laugh. Apparently they had been translated from the IBM documentation into Japanese, and then translated back into English. They were both awful, difficult to read and understand, and sometimes very funny in the poorly translated phrases that appeared regularly. I also recall that there was a serious dispute between my then employer and IBM, which led to the buying of Fujistu at the time. IBM tried to get the decision reversed. The story I heard was that the local head of IBM took the government minister responsible for the organisation out for a round of golf together... This may have been just be a rumour though, the people involved are long ago retired. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH408I error during Setup and use of the zSecure Visual Server 2.4.0
Hi Kayhan, I see you received suitable answers to your questions on the IBM forum for zSecure here: https://community.ibm.com/community/user/security/communities/community-home?communitykey=44eb7c0d-9bc2-419b-9158-ad693e734065&tab=groupdetails I would recommend anyone working with any of the zSecure products aka ex-Consul RACF Admin/Audit etc use this forum instead of asking questions here on IBM-Main, you're much more likely to get a correct and rapid response there. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM z/OS Authorized Code Scanner
It looks very much like the z/Assure from Key Resources and Ray Overby were doing, which I note is now offered via BMC. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Profiles specific to user
Unfortunately the SEARCH command only applies to the user executing the command. Returning the profiles that *you*, the executing user, have access to. I think what Vignesh is asking for is a list of the profiles for a given user when asking the question as an administrator. Others have pointed out, you can use the IRRDBU00 unload and process the records yourself, however you need to write the logic: a) Start with the user, retrieve the list of Groups the user is connected to, add the user itself to the list of groups. b) Search the Access List entry records in Dataset class for any entry that matches any of the list you generated in (a) Beware, that you then have to figure the logic yourself if you also want to know what level of access - if the users is in two groups that have access to a specific profile, the highest level of access is the one that applies. If the userid itself appears in the access list, the level of access associated with that access list entry applies. Note we haven't figured UACC into the equation, nor conditional access, nor a number of other ways that users might access resources (i.e. administratively). This is why RACF management tools exist... You could ask the user to execute the SEARCH command themselves, or provide a small REXX wrapper around the SEARCH command for them. There might also be something useful in the Pentland Utilities on https://www.nigelpentland.co.uk/ Hope this helps, regards - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Being a RACF geek and a contractor for roughly half my career I've seen most of the conventions people have shared here in this thread. The best laugh I get talking with other mainframe geeks though was from a large bank where the algorithm went: First 5 letters of SURNAME + first initial of first name + first initial of middle name. Either of the last two single character fields could be cycled upwards alphabetically (starting from 'A') until a unique string was obtained in case the generated one was already allocated to someone. So my middle name is Francis and my userid became CAIRNCF - Cairns was a not uncommon surname in these parts, and thus I didn't get my forename in position 6, but did get my middle initial in position 7. The unfortunate fellow who's name is indelibly burned into my mind (and no doubt he has never heard this story) was Keith Allen Mumford - who the algorithm spat out as MUMFOKA... We decided to simply revoke that userid and roll the dice again. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
Hi Radoslaw, You can find the list that IBM recommends in the MVS Init and Tuning Guide: https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa231380/$file/ieae200_v2r3.pdf I worked at one site many years ago where the local specialist had actually tested across multiple IPL's the necessity for each and every one of these tasks to actually have the TRUSTED attribute and the conclusion was that many of these did not actually need to be TRUSTED and could manage perfectly fine using normal RACF access to resources granted via permissions to profiles. IIRC we did encounter one or two started tasks that while they were able to run across IPL's without the TRUSTED attribute, there were pseudo-random occurrences of permissions problems that we never did get to the bottom of and IBM could not explain to us either at the time. In the end, we capitulated and granted the TRUSTED attribute. HTH - Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Automation (Cross Posted)
The last major RACF project I architected was for something I presume would probably fit your clients bill here. Some of the necessary elements we incorporated were: Delegated (though not via RACF means) Ownership of all RACF general resource and dataset profiles - thereby making sure that there were people distributed throughout the organisation who a) knew what their security requirements were, at least conceptually, and b) took responsibility for authorising requests for access to or changes made to the RACF definitions they 'owned'. A naming convention that meant ownership of RACF definitions was able to be related to specific application systems (z/OS itself was considered just another application system running on the mainframe also - it's owner was of course the systems programming management). A request workflow that walked ordinary users through the process of raising a change record for RACF definitions. We used ServiceNow for this, with heavily customised workflows that linked into a Configuration Management Database that was a mirror, refreshed frequently, of the content of the RACF database. The previously mentioned CMDB was an essential part of ensuring that we had auditable, documented, reliable oversight - governance they like to call it nowadays - of the process of RACF change management. The CMDB relied heavily on the naming convention being used to identify which application (and therefore which responsible Owner) would be allowed to authorise requests. An in house written started task that issued the necessary RACF commands based on authorised changes coming through the ServiceNow workflow. Standardisation of the format for Installation Data - which we used to describe things such as a profiles security classification - i.e Public, Internal, Confidential, Secret - something like that, the labels are up to you. This 'data classification' was used to provide different versions of the ServiceNow workflow to suit the sensitivity of the resources being manipulated. (I would have liked to use/abuse SECLABEL/SECLEVEL for this but that made some people nervous :-). A lot of SMF based audit reports, especially with respect of the more highly classifiied resource profiles. Two years work with a couple of sysprogs, a project manager and assistant plus a great deal of support from the organisations management to get this task done. The alternative, was that we were going to need a team minimum 4 people with solid RACF knowledge to be available as mainframe security management - so the cost benefit analysis was quite crystal clear. There were many other considerations that our RACF Automation project had to consider, and we solved a lot of other historical audit related issues during the process also and were very fortunate that we could implement some worlds best practice mainframe security constructs (i.e. separating all batch access on an application by application basis) as a part of the project. Happy to discuss offline in case anyone is interested. Cheers - Mike PS: the organisation already had a fully integrated IAM solution for provisioning mainframe access and an RBAC-like construct for this, that's the easy part - anyone without this nowadays is simply dragging the chain. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "The Computers Nobody Wanted"
That's a brilliant read, thanks for posting. Amazing to see the perspective of an early CIO in action considering the S360 offerings against their competitors as things looked to them at the time. And also a brilliant exposition of what really happened at Xerox from someone with a seat at the table, together with some harsh and true insights into the preference for Marketing over Data in CxO level discussions that has prevailed in corporate boardrooms for far too long now. References to BBN and J.C.R. Licklider are consummately covered also in one of my favourite books about this era, Where Wizards Stay Up Late https://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674. He could do with an editor and proof reader though. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "The Computers Nobody Wanted"
I sent this privately to the OP at first, who liked it and suggested I re-send it to the entire group as the thread is already OT and others might like the story also. My father, 86 now, became fascinated with computers in the late 50's early 60's during his first career as a surveyor and map maker when maps were still hand drawn (cartographer I believe was his official title). Back in those days in Australia they were still mapping the continent, and part of the work consisted of going out in teams of 3 guys who would drive a topless (often doorless also) landrover to the peak of a local hill, and camp up there for a few days while they assembled the trigonometry station out of pipe steel and self made concrete on the spot. Hard work, tough men, and lots of beer was consumed I'm told. Dad wanted more and started studying a bachelors in computer science, one of the first offered in Australia at the time, with the Canberra College of Advanced Education (like an apprenticeship but for more technical trades) in about 1967, completing it (part time as evening classes mostly) in 1972. Apparently for his final assessment on the course, they had to write a compiler (don't know what language was to be compiled) for the PDP-11 the college had. This was only an undergraduate course - these guys were super smart and worked extremely hard - I've worked with IT graduates of today, and most of them could not have done what these guys were doing back in the 70's. The writer of the Xerox article reminds me a lot of my dad. These were thoughtful, considered and hard working people who had come through the worst of what the world could throw at them growing up between two world wars and eagerly accepted the opportunities presented to them by this new world of technology. After graduation Dad then went on to spend the rest of his working life with the Australian Bureau of Statistics, where they ended up writing mostly PL/1 on the Fujitsu mainframe that replaced their IBM kit (a choice that almost got the department in big trouble with their government overseers, as IBM executives played golf with the relevant parliamentary ministers). Almost 20 years later I cut my teeth in PL/1 on the same Fujitsu environment, upgraded many times since of course. Strangely though, my next shop was an Amdahl machine, and the shop after that a Hitachi even into the late 90's. I had been working with 'IBM mainframes' for more than ten years before I ever saw one actually from IBM! :-) Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How To Handle RACROUTE logic
You don't need to concern yourself with *how* the user is (or is not) given access to the resource. You don't need to concern yourself with which RACF profile protects the resource either. You just pass the necessary information about the user, the access level being requested and the resource name to the RACROUTE call and RACF determines the answer for you. This answer might be because the user is permitted directly on the access list of the profile covering the resource, or one (or more) of the groups they are a member of is on the access list, or the resource might grant access via the Universal Access attribute, or the user might have some other ability such as Operations, or even a RACF exit might get into the equation and contribute to the answer your RACROUTE call gets back. It's all 'under the covers'. In general, it's a bad idea to try and second guess RACF by assuming that some named Group or other structure is used specifically to make access decisions - poor design choice (made all too often by folks who don't really understand RACF). One important difference you might need to be aware of is between a normal RACROUTE call that executes under the authority of the current user associated with the running address space (a First Party call - i.e. checking your own current access rights), and the special case known as Third Party RACROUTE call where you also give the userid on the call and it's not necessarily the same userid as you are executing under at the time. For this, you need first to create a new RACF ACEE and pass this to the RACROUTE call - IIRC this *requires* you to have APF Authorisation (actually, Supervisor State, however you get that, but most commonly this means you are APF'd), IOW you won't be doing this from a normal user address space. HTH - Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
As an Australian I can vouch for the veracity of the noted definition of the word 'root', although I would also suggest that this usage was almost always confined to a younger generation and seems to be someone one grows out of. :-) Then there is the standard Aussie joke we tell about Kiwi's (another slang word for people from New Zealand, and also a small flightless bird that ferrets around in the undergrowth for food): "I'd like to be a Kiwi, 'cos he eats roots and leaves". Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data Set Commander Monitor (DSCMON) Access Authority
Hi Rob - is it now considered less than best practice to allow Linklist and LLA etc to fall under UACC(READ) or ID(*) READ profiles? MY recollection is that these libraries are not fetch protected, and therefore there is little common sense in having them anything other than UACC(READ)... Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data Set Commander Monitor (DSCMON) Access Authority
No Bob - I meant UACC(READ) or its equivalent. I just don't see what gate is being closed by insisting that LinkList or LPA libraries must have UACC(NONE), when, as you confirm, they cannot be fetch protected and therefore the content is available to anyone on the system anyway. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data Set Commander Monitor (DSCMON) Access Authority
Hi Peter, Radoslaw and I probably spend more time over on the RACF_L list than here on IBM-MAIN, but I still like to keep an eye open here. The use of ID(*) ACCESS(READ) is well known among the RACF community as the 'preferred' option to UACC nowadays, and the reason you cite is indeed mentioned in the literature. Though I'm not sure about the NJE port of entry still being able to actually get a batch job running under the JES UNDEFINEDUSER, I have a recollection that the RACF SETROPTS setting BATCHALLRACF(YES) should prevent a batch job from initiating with the UNDEFINEDUSER value, though I have a vague recollection that BATCHALLRACF itself has been redundant also for many years now as well. I'm intrigued generally to ask of this community, just how often does anyone observe work executing on their system *without* a valid RACF (or ACF2 or TopSecret) identity associated with it? I think there might still be one or two started tasks, probably running as TRUSTED or PRIVILEGED, that are initiated in nucleus initialisation that may still run with traditionally either the 8 plusses or the 8 question marks as their ID, we can see them in SDSF, but realistically I don't believe that we see work running under the UNDEFINEDUSER in modern systems for a long time nowadays. I'd be keen to hear otherwise if there is though. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
