学习主机及 具有 Java/OOP/SQL 背景的 JCL

发布于 2024-07-15 13:02:25 字数 1431 浏览 11 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

花桑 2024-07-22 13:02:26

现代大型机中没有打孔卡,它们只是让您使用。

你会遇到困难,因为仍然有很多事情是以“旧”方式完成的。

  • 数据集仍然分配有固定块80、可变块255等属性。 规划您的文件内容。
  • 没有目录。 有层次结构,每个层次最多只能有 8 个字符。
  • 用户界面是ISPF,这是一个来自第七层地狱的绿屏文本模式用户界面,适合那些不习惯它的人。
  • 大多数作业仍将作为批处理作业提交,您必须使用 SDSF(某种任务管理器)监控它们的进度。

这是一些坏消息,这是好消息:

它有一个 USS 子系统 (UNIX),因此您可以使用这些工具。 它与 z/OS 集成得非常好。 它运行 Java,它运行 Websphere,它运行 DB2(真正的 DB2,不是那么小的 Linux/UNIX/Windows),它运行 MQ 等等。许多商店还将运行 z/VM,一种虚拟机管理程序,在这种管理程序下,他们将运行许多 LPAR(逻辑分区),包括 z/OS 本身(有时是多个副本)和 zLinux (SLES/RHEL)。

大型机短期内不会有消失的危险。 世界各地的各个 IBM 实验室仍在进行大量工作,64 位操作系统(z/OS、MVS、OS/390,...)已经取得了长足的进步。 事实上,这里有一些职业机会,因为所有知道这一点的老员工都在 55 岁或以上,所以如果你正确定位自己,预计在公司阶梯上会有巨大的吸力。

它仍然在大公司中使用,因为它是他们的交易中唯一可以信任的东西 - System z 中的 z 意味着零停机时间,这不仅仅是营销炒作。 大型机的强大之处不在于它的 CPU 性能(单个处理器不是那么强大,但它们是具有热备份的 54 个 CPU 的书籍,您可以在单个 System z 机器中运行许多书籍),但事实上CPU 所做的只是处理指令。

其他都被卸载到专用处理器、用于 DB2 的 zIIP、用于 Java 工作负载的 zAAP、用于 I/O 的其他设备(而 I/O 是大型机使用光纤和杀死所有其他系统的地方>非常大的磁盘阵列)。 我不会将它用于蛋白质折叠或基因组测序,但它非常适合目标交易处理的疯狂水平。

正如我所说,z/OS 有一个 UNIX 子系统,z/VM 可以运行 z/OS 和其他操作系统的多个副本 - 我见过一个 z800 机器同时运行数万个 RHEL 实例。 这让所有 PC 制造商的“绿色”声明感到羞愧,并且使用 HyperSocket(TCP/IP,但使用共享内存而不是通过慢速网络电缆,实例之间的通信速度快得令人眼花缭乱(是的,与 HyperSocket 相比,甚至是千兆位以太网也会爬行(抱歉,嵌套括号:-)))。

它在 Unix 空间中很好地运行 Websphere Application Server 和 Java,同时仍然允许所有遗留(遗产?)的东西运行。 事实上,大型机商店根本不需要购买基于 PC 的服务器,他们只需投入一些 zLinux VM 并在一台机器上运行所有内容即可。

最近,有传言称 IBM 也可能为其大型机提供 xSeries(即 PC)插件设备。 虽然大多数大型机用户会认为这是他们美丽的盒子侧面的一个疣,但它确实为第三方供应商开辟了很多可能性。 我不确定他们是否能够运行 50,000 个 Windows 实例,但这似乎正是他们的目标(一环统治所有实例?)。

如果您有兴趣,有一个名为 Hercules 的 System z 模拟器,我见过它在 Windows 机器上以 23 MIPS 的速度运行,并且它运行最后一个合法可用的 MVS 3.8j 的速度足够快,足以感受一下。 请记住,MVS 3.8j 之于 z/OS 1.10 就像 CP/M 之于 Windows XP。

要为我的一位工作朋友写的书提供无耻的插件,请查看 What On地球是一个大型机? 作者:大卫·斯蒂芬斯 (ISBN-13 = 978-1409225355)。 我发现这非常宝贵,因为我有 PC/UNIX 背景,而且这是一个相当大的范式转变。 我认为这本书非常适合解决您的特定问题。 我认为其中的大部分内容都可以在 Google 图书上找到,因此您可以在购买前尝试。

关于 JCL,有一种思想认为只编写了一个 JCL 文件,所有其他文件都是在该文件上剪切和粘贴的。 看了他们的内容,我就明白了。 像 IEBGENER 和 IEFBR14 这样的程序使 Unix 看起来即使不冗长,至少也是可以理解的。

There are no punch cards in modern mainframes, they're just having you on.

You will have a hard time since there are still many things done the "old" way.

  • Data sets are still allocated with properties such as fixed-block-80, variable-block-255 and so on. Plan your file contents.
  • No directories. There are levels of hierarchy and they're limited to 8 characters each.
  • The user interface is ISPF, a green-screen text-mode user interface from the seventh circle of hell for those who aren't used to it.
  • Most jobs will still be submitted as batch jobs and you will have to monitor their progress with SDSF (sort of task manager).

That's some of the bad news, here's the good news:

It has a USS subsystem (UNIX) so you can use those tools. It's remarkably well integrated with z/OS. It runs Java, it runs Websphere, it runs DB2 (proper DB2, not that little Linux/UNIX/Windows one), it runs MQ, etc, etc. Many shops will also run z/VM, a hypervisor, under which they will run many LPARs (logical partitions), including z/OS itself (multiple copies, sometimes) and zLinux (SLES/RHEL).

The mainframe is in no danger of disappearing anytime soon. There is still a large amount of work being done at the various IBM labs around the world and the 64-bit OS (z/OS, was MVS, was OS/390, ...) has come a long way. In fact, there's a bit of a career opportunity as all the oldies that know about it are at or above 55 years of age, so expect a huge suction up the corporate ladder if you position yourself correctly.

It's still used in the big corporations as it's the only thing that can be trusted with their transactions - the z in System z means zero downtime and that's not just marketing hype. The power of the mainframe lies not in it's CPU grunt (the individual processors aren't that powerful but they come in books of 54 CPUs with hot backups, and you can run many books in a single System z box) but in the fact that all the CPU does is process instructions.

Everything else is offloaded to specialist processors, zIIPs for DB2, zAAPs for Java workloads, other devices for I/O (and I/O is where the mainframe kills every other system, using fibre optics and very large disk arrays). I wouldn't use it for protein folding or genome sequencing but it's ideal for where it's targeted, massively insane levels of transaction processing.

As I stated, z/OS has a UNIX subsystem and z/VM can run multiple copies of z/OS and other operating systems - I've seen a single z800 box running tens of thousands of instances of RHEL concurrently. This puts all the PC manufacturers 'green' claims to shame and communications between the instances is blindingly fast with HyperSockets (TCP/IP but using shared memory rather than across slow network cables (yes, even Gigabit Ethernet crawls compared to HyperSockets (and sorry for the nested parentheses :-))).

It runs Websphere Application Server and Java quite well in the Unix space while still allowing all the legacy (heritage?) stuff to run as well. In fact, mainframe shops need not buy PC-based servers at all, they just plonk down a few zLinux VMs and run everything on the one box.

And recently, there's talk about that IBM may be providing xSeries (i.e., PCs) plugin devices for their mainframes as well. While most mainframe people would consider that a wart on the side of their beautiful box, it does open up a lot of possibilities for third-party vendors. I'm not sure they'll ever be able to run 50,000 Windows instances but that's the sort of thing they seem to be aiming for (one ring to rule them all?).

If you're interested, there's a System z emulator called Hercules which I've seen running at 23 MIPS on a Windows box and it runs the last legally-usable MVS 3.8j fast enough to get a feel. Just keep in mind that MVS 3.8j is to z/OS 1.10 as CP/M is to Windows XP.

To provide a shameless plug for a book one of my friends at work has written, check out What On Earth is a Mainframe? by David Stephens (ISBN-13 = 978-1409225355). I found this invaluable since I came from a PC/UNIX background, and it is quite a paradigm shift. I think this book would be ideal for your particular question. I think chunks of it are available on Google Books so you can try before you buy.

Regarding JCL, there is a school of thought that only one JCL file has ever been written and all the others were cut'n'paste jobs on that. Having seen the contents of them, I can understand this. Programs like IEBGENER and IEFBR14 make Unix look, if not verbose, at least understandable.

愿与i 2024-07-22 13:02:26

您的第一个误解是相信 JCL 中的“L”。 JCL 不是一种编程语言,它实际上是程序应如何运行以及应使用哪些文件等的静态声明。

通过这种方式,它很像(尽管优于)用于控制 spring、hebernate 和 ant 等“现代”软件的 xml 配置 spahetti。

如果你用这些术语来思考,一切都会变得清晰。

大型机文化是由两种看似不相容的痴迷驱动的。

  1. 向后兼容性。 您仍然可以运行 1970 年编写和编译的可执行文件。四十年前的 JCL 和脚本仍然可以运行和工作!
  2. 一流的性能。 您可以在两个数据中心的四台机器上使用 128 个 CPU 来处理单个 DB2 查询。 它将比任何其他机器更快地运行最新的 J2EE (Websphere) 应用程序。

You first misconception is beleiving the "L" in JCL. JCL isnt a programming language its really a static declaration of how a program should run and what files etc. it should use.

In this way it is much like (though superior to) the xml config spahetti that is used to control such "modern" software as spring, hebernate and ant.

If you think of it in these terms all will become clear.

Mainframe culture is driven by two seemingky incompatable obsessions.

  1. Backward compatability. You can still run executables written and compiled in 1970. forty year old JCLs and scripts still run and work!
  2. Bleeding edge performance. You can have 128 cpus on four machines in two datacentres working on a single DB2 query. It will run the latest J2EE (Websphere) applications faster than any other machine.
紫瑟鸿黎 2024-07-22 13:02:26

如果您曾经参与过 Z/OS 上的 CICS(大型机事务服务器),我会推荐“设计和编程 CICS 应用程序”一书
这非常有用。
替代文本 http://img18.imageshack.us/img18/7031/designingandprogramming.gif< /a>

If you ever get involved with CICS (mainframe transaction server) on Z/OS, I would recommend the book "Designing and Programming CICS applications".
It is very useful.
alt text http://img18.imageshack.us/img18/7031/designingandprogramming.gif

烦人精 2024-07-22 13:02:26

如果您打算参与传统的遗留应用程序开发,请阅读 Steve Eckols 的书籍。 他们都很好。 您需要比较从开放系统到大型机的术语,这将减少您的学习时间。 几个例子
文件在大型机上称为数据集
JCL更像是一个shell脚本
子程序/例程或常用功能等...祝你好运...

If you are going to be involved with traditional legacy applications development, read books by Steve Eckols. They are pretty good. You need to compare the terms from open systems to mainframe which will cut down your learning time. Couple of examples
Files are called Datasets on mainframe
JCL is more like a shell script
sub programs/routines or like common functions etc...Good luck...

婴鹅 2024-07-22 13:02:26

一开始握的手越多越好。 我曾作为实习生在大型机上做过工作,尽管我有相当深厚的 UNIX 背景,但这并不容易。 我建议请在大型机部门工作的人花一两天的时间教您基础知识。 IBM 培训可能也有帮助,但我没有任何经验,因此不能保证一定会有帮助。 我在下面讲述了有关学习如何使用大型机的故事。 决定所有实习生将学习如何使用大型机作为暑期项目,占用 20% 的时间。 这完全是一场灾难,因为所有实习生都承认我在非大型机区域工作,而且没有人可以隔着立方体墙大声呼救。 ISPF 和 JCL 的环境对于他们来说是陌生的,无法快速熟悉。 他们唯一的成功是在 USS 下进行基本编程,因为它基本上是 UNIX,大学让他们熟悉了这一点。 我的运气更好有两个原因。 其中一个是我在一个由大约 20 名大型机程序员组成的小组中工作,因此能够有人定期坐下来帮助我弄清楚 JCL、提交作业等。其次,我使用了 Rational Developer for System z(当时它被命名为 WebSphere Developer for System z)。 这为我提供了一个最可用的 GUI,让我可以执行大多数任务,例如提交作业、编辑数据集、分配数据集、调试程序等。虽然它尚未完善,但已经足够可用,意味着我不必学习 ISPF。 事实上,我有一个基于 Eclipsed 的 IDE 来执行基本的大型机任务,这显着降低了学习曲线,这意味着我只需学习 JCL 等新技术,而不是全新的环境。 进一步说明,我现在使用 ISPF,因为允许 Rational 在大型机上运行所需的软件没有安装在我使用的生产系统之一上,所以 ISPF 是唯一的选择。 我现在发现 ISPF 比 Rational Developer 更快,而且我使用它的效率更高。 这只是因为后来我能够通过Rational学习JCL和ISPF接口等底层技术。 如果我必须同时学习两者,那就会困难得多,并且需要更多的一对一指导。

The more hand holding at the beginning the better. I've done work on a mainframe as an intern and it wasn't easy even though I had a fairly strong UNIX background. I recommend asking someone who works in the mainframe department to spend a day or two teaching you the basics. IBM training may be helpful as well but I don’t have any experience with it so can’t guarantee it will. I’ve put my story about learning how to use the mainframe below for some context. It was decided that all the interns were going to learn how to use the mainframe as a summer project that would take 20% of there time. It was a complete disaster since all the interns accept me were working in non mainframe areas and had no one they could yell over the cube wall to for help. The ISPF and JCL environment was to alien for them to get proficient with quickly. The only success they had was basic programming under USS since it’s basically UNIX and college familiarized them with this. I had better luck for two reasons. One I worked in a group of about 20 mainframe programmers so was able to have someone sit down with me on a regular basis to help me figure out JCL, submitting jobs, etc. Second I used Rational Developer for System z when it was named WebSphere Developer for System z. This gave me a mostly usable GUI that let me perform most tasks such as submitting jobs, editing datasets, allocating datasets, debugging programs, etc. Although it wasn’t polished it was usable enough and meant I didn’t have to learn ISPF. The fact that I had an Eclipsed based IDE to do basic mainframe tasks decreased the learning curve significantly and meant I only had to learn new technologies such as JCL not an entirely new environment. As a further note I now use ISPF since the software needed to allow Rational to run on the mainframe wasn’t installed on one of the production systems I used so ISPF was the only choice. I now find that ISPF is faster then Rational Developer and I’m more efficient with it. This is only because I was able to learn the underlying technology such as JCL with Rational and the ISPF interface at a later date. If I had to learn both at once it would have been much harder and required more one on one instruction.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文