$ HASP373和IEF403I z / os syslog

时间:2014-04-13 12:41:51

标签: mainframe zos

我问自己一个关于z / os日志的问题:

我只是想知道所有开始的操作是否总是被$ HASP373和IEF403I调用? 对于由$ HASP395和IEF404I调用的状态Ended?

5 个答案:

答案 0 :(得分:7)

z / OS的问题在于,在没有引入另外需要解释的概念的情况下,真的难以解释。反过来,这需要另外的解释等。这部分是由于z / OS操作系统来自与Unix,Windows,OS X等相比的不同星球,所有这些都大致相似。

这些消息由系统发布,用于大型机上发生的大量工作,但不是全部。

z / OS上的所有工作都在自己的地址空间中运行,这几乎就像一个迷你虚拟机。 z / OS系统中将有许多地址空间(目前我们有380个)。地址空间中的程序不知道任何其他地址空间,并认为它可以访问整个2Gb(31位寻址)内存范围(不同的地址空间可以进行通信,如果需要和授权,64位寻址可提供2GB以上的数据。一个地址空间中的程序不能通过覆盖存储来使另一个地址空间中的程序崩溃。 2个不同地址空间中的程序可以访问相同的内存地址,但不会相互影响,因为它们实际上是不知道的,它们访问不同的内存。

有4种类型的地址空间:

  • TSO(时间共享选项) - 这些是用户登录系统,输入命令和获取响应。他们可以运行脚本,使用语言REXX和Clist(命令列表 - 较旧,通常由REXX替换),就像Perl和shell脚本,提交批处理作业,编写和编译代码等。
  • BATCH JOBS(或JOB) - 这是您要运行程序的位置,因此您创建一个文本文件,其中包含要运行的程序的名称以及它/它们需要的文件(s )并提交它。系统将运行程序并告诉您何时完成,在运行时,您可以继续执行其他操作。您甚至不需要登录 - 您可以准备一个FTP作业(例如)在您睡着的时候在01:00运行,如果第一个工作则运行另一个工作。
  • STARTED TASKS(STC) - 与批处理作业非常相似。通常在系统启动时由系统本身启动,或者由操作员在系统控制台发出该STC的START命令启动。 (例如,“START DB2”启动DB2启动任务。或者,用户可以为自己的测试DB2系统提交批处理作业。)

  • 系统地址空间(SYSAS)。将它们视为Unix守护进程。由操作系统本身开始,用于各种基本过程。还有地址空间表示在z / OS(USS - Uxniz System Services)的'Unix'一半下运行的进程,但这是另一个故事。

在z / OS术语中没有“操作”这样的东西。在地址空间内,许多程序可能正在运行,每个程序都由TCB(任务控制块)或SRB(系统请求块)识别。

但是,如果您知道您想要的信息是由正常的批处理作业生成的,那么查找该作业的£HASP373和£HASP395消息将是正确的起点。请记住,消息ID(HASP373和HASP395)可能不会以系统上的“£”开头。 '£'是默认值,但它是一个可自定义的参数。 $和#也很常见。

我确实知道我在说什么,但如果上述任何一项都不清楚,那我就没有解释清楚。我可能会犯下我所发出警告的内容,并通过使用另一个未知概念解释一个未知的概念。 : - )

答案 1 :(得分:3)

工作通过称为子系统接口的东西进入z / OS。这个流程的一部分通常是,当地址空间启动时,它通过一个定义良好的接口(IEFSSREQ)从启动地址空间的子系统请求工作。这种握手是HASP消息之类的来源。

这是一个淡化的例子。

操作员从系统控制台输入START命令。作为处理该命令的一部分,系统创建了一个地址空间,最终新地址空间中的一个线程说,“好了 - 我准备好了......给我一些工作要做"。这将转到主要作业输入子系统,该子系统负责处理地址空间要做的事情 - 内部数据结构表示操作员在这种情况下启动的任务。作为此链的一部分,将发布各种$ HASP消息,这与TSO会话,启动任务(STC)和为批处理作业提交的JCL的工作方式大致相同。

JES2 / JES3是子系统的示例,但还有其他子系统。

例如,如果我们的操作员在启动命令中添加了SUB = MSTR参数,则请求将不会通过主JES - 因此不会出现任何$ HASP消息&# 39;重新寻找。有许多供应商应用程序可以启动和管理JES之外的地址空间,这是您通过限制HASP和IEF401消息而错过的内容。

此外,UNIX服务有各种类似于UNIX" fork"的API。可用于生成地址空间而不必涉及JES。

如果您想了解活动的开始和结束,有更好的方法 - SMF,ENF信号等。如果您不知道已经使用系统跟踪设施,那么学习这些东西的好方法读一些转储。关于z / OS的精彩之处在于,它可以用于那些花时间搞清楚外观的人。

答案 2 :(得分:2)

没有。 Those messages适用于jobs。并非所有操作都是工作。非作业的操作示例是system command。我现在手头没有z / OS系统,但我相信另一个不使用你引用的消息的操作示例将是一个启动任务。

This可能会有所帮助,因为它试图用Unix来解释z / OS概念。

答案 3 :(得分:2)

工作是通过JES2 / JES3完成的。 (在您的情况下,JES2。)JES2 / JES3作业通常用于批处理类型的工作。例如,一个排序作业,我提交的东西,然后回来并得到答案。但是,在z / OS下运行的大量工作并没有通过JES2 / JES3。

这里的部分问题是您的操作意味着什么;例如,虽然您可能会收到一条消息,说DB2已经启动,但在它启动后,它不会在每次查询时都会告诉您。 TSO用户可能会在他/她的地址空间下运行REXX exec,但这不会通过JES。

另一种看待这种情况的方法是JES2 / JES3是作业管理子系统,但它们并不等同于unix / windows系统上的内核,它确实安排了系统上运行的所有工作。对于z / OS,工作可以通过多种方式进入系统;示例包括JES2 / JES3,TSO,ISPF,CICS,DB2,IMS,通过控制台等。然后由主调度程序/ WLM / SRM管理通过所有子系统进入的所有请求。 。

如果您有权访问z / OS系统,请查看SDSF或用于管理JES2的任何内容。在SDSF下的ST面板是由JES2管理的正在运行/有资格运行的事物的列表。但是,如果您查看DA面板(假设您有权这样做),您会注意到DA面板上显示的很多地址空间不会出现在ST小组。

答案 4 :(得分:0)

如果通过JES2子系统启动地址空间(除非使用MVS START命令指定了另一个子系统或MSTR,否则通常是这种情况),则发出$ HASP373作业名STARTED。同样,当地址空间结束时,将发出消息$ HASP395。

IEF403I和IEF404I消息是由系统在类似情况下发出的,与JES2或JES3所做的事情无关,并且与在哪个子系统下启动地址空间无关。仅当操作员请求使用SETCON MONITORMONITOR JOBNAMES命令监视作业名称时,才发出消息。用于自动化操作的产品通常会这样做。