IBM Mainframe Forum

Im wondering if anyone knows if anyone offers z/OS shell accounts, free or at cost?
I want to some learn PL/I programming

I am aware of one source, but it is intended for fairly experienced people that do not need very much, if any, assistance. The terminology you're using ("shell account," a term that is not used in the z/OS world) strongly suggests you are not a member of that population. Before you start in with z/OS PL/I, you would have to learn at least the basics of dealing with z/OS and TSO.

Steve- I just recently found out that z/OS is very different from unix flavored OSes, so I think its true what you say that I would first have to learn the z/OS to use it. But I guess there is no harm is asking to see if maybe someone runs z/OS in their home for fun and would be willing to let people log on. I think getting online training is my most realistic option from a place like this:
http://www.datatrain.com/library.aspx?id=2639

Hello,

What about z/OS do you want to learn? Anything specific or just to become familiar with the environment?

If you want to learn basic familiarity, and you are willing to put in more than just a little effort, you might consider installing Hercules on your own machine. Once Hercules is successfully installed, you can then install an older release of MVS (the forerunner of z/OS) and you basically have a mainframe running on your own pc.

To learn more about Hercules, suggest you do a web search for hercules emulator. The link you want will probably be the first "hit".

Thanks Dick, I actually have heard of the Hercules emulator. Im really surprised that IBM doesnt do more to provide student and trial versions of its software to run on x86, theyre cutting themselves off from potential new users. z/OS I believe is related to OS/360 which is one of the oldest operating systems, Im very curious how it differs with todays standard *nix OSes. Im more interested in PL/I though.

Hello,

Well pl/i is like cobol in that it is quite similar across platforms

All of the LUW (Linux, UNIX, Windows) "stuff" has many similarities. None of them resemble z/OS, MVS, etc. All of those mainframe environments greatly resemble each other. Two of the biggest differences are the "file systems" and the internal collating sequence. OS/360 was for the IBM Model 360 hardware. Across many new hardware implementations, there have been new operating systems - until z/OS which is current.

Recently, IBM has been pushing Rational Developer to attract more/new users. You may want to look into this. To use RDz, i believe there is a fee rather than it being free but i'm not positive about this.

Brad Cantrell wrote:...z/OS I believe is related to OS/360 which is one of the oldest operating systems, Im very curious how it differs with todays standard *nix OSes. ...

OS/360 is the great great granddaddy of z/OS. At least in theory, a load module for problem state execution for an OS/360 Release 1 system will run, unchanged, on z/OS. Similarly, the Assembler source for this program will assemble, unchanged, on z/OS. Programs using anything more than very basic system facilities in OS/360 Release 1 will probably fail in z/OS; similarly not even the most basic object code from z/OS can be made to run in OS/360 Release 1 because some Assembler macros (GET, PUT, READ, WRITE, CHECK) generate instructions that do not exist in System/360

The system structure of Unix is both similar to, and different from OS/360. OS/360 did not have the concept of a Unix "process," though the ultimate development of OS/360 (OS/360 MVT) did have the concept of what is called a "thread" in Unix. Even the most primitive form of OS/360 used a Task Control Block, though it was simply used as an anchor for some control blocks; it was not used for dispatching work like a thread in Unix since there was just one in the system.

One big difference between OS/360 and its derivatives and Unix is there is a lot of shared storage in the system. In this sense z/OS is much more wide open than Unix. A knowledgeable programmer can find out much more information about what is running in the system by examining system control blocks in shared storage than is possible in Unix; in OS/360 all of this was open; MVS blocks quite a lot of this snooping, but a surprising amount is still available.

However, the file system and file structures in OS/360 (and in z/OS) are much different than in Unix. Unix does not have file structures as they are known in OS/360 (and z/OS); file structures are defined exclusively within an application in Unix, though "text" files in Unix have a more or less standard format. On the other hand, OS/360 "data sets," which are similar in concept to Unix files, have several formats that are recognized by the system.

OS/360 does not have a directory structure like Unix, though the OS/360 VTOC is similar in concept to a single directory (or possibly the root directory of a file system) in Unix. OS/360 does not have a directory (VTOC) pointing to another directory. An OS/360 "volume" is sort of equivalent to a "file system" in Unix, but "volume" is tied a physical device in OS/360. Most "volumes" in OS/360 were removable, in the sense that a disk pack could be taken out of a drive and replaced by another disk pack/"volume." This is not true any more, but the volume concept has been retained.

Thanks for the info Steve. I just got a book on z/OS and it looks like a lot of things about it are more robust whereas everything on unix seems to be just utilities that make system calls. I think its worth looking into for anyone who wants to become a sys admin, to look into the capabilities of z/OS workload compared to *nix. I really got to get good at programming before I dedicate any time to study operating systems. So far PL/I looks like a better option to C as far as systems programming. Everybody just seems to blindly accept the C and unix ways of doing things.

The C language is a good system programming language, even in the z/OS world. IMHO, its only real weakness in System/360 type hardware is the lack of a true bit constant which would readily enable the use of the TM hardware instruction rather than the clumsy if ( variable & constant ) ... construction, though one should be careful in drawing that conclusion.

In the z/OS world PL/I is not seen as a good systems programming language. Rather, it is seen as a language for business applications. PL/I's primary weakness as a systems programming language is its behind the scenes use of a library for program entry and exit, as well as other issues. As far as I know, there is nothing like "Metal PL/I," to reflect an option with z/OS C, to reduce the use of the library and make it a more suitable replacement for Assembler. Yes, I know Multics (another operating system that had some influence on Unix) was done in PL/I, but Multics has been dead and buried for years.

Starting in the early 1970s, IBM developed its PL/S language, quite similar to PL/I, for systems use. One oddity about PL/S is the compiler emits real Assembler code rather than object code like most compilers, so a PL/S compile is the compile plus an assembly to produce object code. Like C, PL/S has no I/O defined in the language. In fact, it does not even have a library with library functions! IBM never released PL/S for customer use, and when someone developed something like a PL/S knock off IBM forced them out of business using copyright violations as an excuse.

I think "... everything on unix seems to be just utilities that make system calls." is a very shallow analysis of Unix. Fundamentally, all application code is business required logic interspersed with system calls, regardless of the operating system. System control in Unix is nearly as good as z/OS, which is the underpinning of its popularity.

Far be it for me to stick up for Unix! I'm a z/OS guy through and through. There is a piece of me that wishes Unix had never happened. z/OS forever!

Hello,

One must take care to see/find more than what they already expect. . .

whereas everything on unix seems to be just utilities that make system calls.

Somewhat incomplete and rather an over-simplification *

Everybody just seems to blindly accept the C and unix ways of doing things.

This was somewhat true in the 80's. . . What is the "C and unix" way to you? As compared to some other environment?

This is not to contradict but rather to suggest that when one is starting to learn multiple new concepts from the very basics, it is best not to form heavy conclusions until considerable foundation has been established.

d

* based on what became my biggest Unix project (which was also the first time i worked in the Unix environment) - i was asked to be the technical project lead for an effort to completely migrate the entire application inventory of an MVS environment (4 mainframes) to HP-UX. The project was basically 20+ databases with a total of around 450 tables and all of the supporting application code, utility functions, and jcl (scripts on Unix). It took slightly over 2.5 years . . .