Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-printmib-job-monitor-00.txt < prev next >

Wrap

Text File | 1997-04-29 | 189KB | 4,836 lines

Job Monitoring MIB, V0.81 April 24, 1997 INTERNET-DRAFT Ron Bergman Dataproducts Corp. Tom Hastings Xerox Corporation Scott Isaacson Novell, Inc. Harry Lewis IBM Corp. April 1997 Job Monitoring MIB - V0.81 <draft-ietf-printmib-job-monitor-00.txt> Expires Oct 24, 1997 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet-Draft specifies a set of 13 SNMP MIB objects for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Bergman, Hastings, Isaacson, Lewis [Page 1] Job Monitoring MIB, V0.81 April 24, 1997 TABLE OF CONTENTS 1. INTRODUCTION 6 1.1 Types of Information in the MIB 6 1.2 Types of Job Monitoring Applications 7 2. TERMINOLOGY AND JOB MODEL 8 3. SYSTEM CONFIGURATIONS FOR THE JOB MONITORING MIB 10 3.1 Configuration 1 - client-printer 11 3.2 Configuration 2 - client-server-printer - agent in the server 11 3.3 Configuration 3 - client-server-printer - client monitors printer agent and server 13 4. CONFORMANCE CONSIDERATIONS 14 4.1 Conformance Terminology 14 4.2 Agent Conformance Requirements 14 4.3 Job Monitoring Application Conformance Requirements 15 5. JOB IDENTIFICATION 15 6. INTERNATIONALIZATION CONSIDERATIONS 16 7. IANA CONSIDERATIONS 17 7.1 IANA Registration of enums 17 7.2 IANA Registration of type 2 bit values 18 7.3 IANA Registration of Job Submission Id Formats 18 8. SECURITY CONSIDERATIONS 18 8.1 Read-Write objects 18 8.2 Read-Only Objects In Other User's Jobs 19 9. RETURNING OBJECTS WITH NO VALUE IN MANDATORY GROUPS 19 10. NOTIFICATION AND TRAPS 19 11. MIB SPECIFICATION 19 Textual conventions for this MIB module 20 JmTimeStampTC - simple time in seconds 20 JmJobSourcePlatformTypeTC - operating system platform definitions21 Bergman, Hastings, Isaacson, Lewis [Page 2] Job Monitoring MIB, V0.81 April 24, 1997 JmFinishingTC - device finishing definitions 21 JmPrintQualityTC - print quality 23 JmTonerEconomyTC - toner economy setting 23 JmMediumTypeTC - medium type definitions 23 JmJobStateTC - job state definitions 24 JmAttributeTypeTC - attribute type definitions 27 other 29 unknown 30 Job State attributes 30 jobState (mandatory) 30 jobStateAssociatedValue 30 jobStateReasons1 31 jobStateReasons2 31 jobStateReasons3 31 jobStateReasons4 31 numberOfInterveningJobs (mandatory) 32 deviceAlertCode (mandatory) 32 processingMessage 32 Job Identification attributes 32 serverAssignedJobName 32 jobName 32 jobServiceTypes 33 jobOwner 33 jobAccountName 33 jobSourceChannelIndex 34 jobSourcePlatformType 34 submittingServerName 34 submittingApplicationName 34 deviceNameRequested 34 queueNameRequested 34 physicalDeviceIndex 35 physicalDeviceName 35 numberOfDocuments 35 fileName 35 documentName 35 jobComment 35 documentFormatIndex 35 documentFormatType 36 Job Parameter attributes 36 jobPriority 36 jobProcessAfterDateAndTime 36 jobHoldUntil 37 outputBinIndex 37 outputBinName (mandatory) 37 sides 37 finishing 37 Image Quality attributes (requested and used) 37 printQualityRequested 37 printQualityUsed 37 tonerEcomonyRequested 38 tonerEcomonyUsed 38 tonerDensityRequested 38 tonerDensityUsed 38 Job Progress attributes (requested and consumed) 38 jobCopiesRequested 38 Bergman, Hastings, Isaacson, Lewis [Page 3] Job Monitoring MIB, V0.81 April 24, 1997 jobCopiesCompleted 38 documentCopiesRequested 38 documentCopiesCompleted 38 jobKOctetsRequested (mandatory) 39 jobKOctetsTransferred (mandatory) 39 jobKOctetsCompleted (mandatory) 40 Impression attributes (requested and consumed) 40 impressionsSpooled 40 impressionsSentToDevice 41 impressionsInterpreted 41 impressionsRequested (mandatory) 41 impressionsCompleted (mandatory) 41 impressionsCompletedCurrentCopy 41 Page attributes (requested and consumed) 41 pagesRequested 41 pagesCompleted 41 pagesCompletedCurrentCopy 41 Sheet attributes (requested and consumed) 42 sheetsRequested 42 sheetsCompleted 42 sheetsCompletedCurrentCopy 42 Resource attributes (requested and consumed) 42 mediumRequestedType 42 mediumRequestedName 42 mediumConsumedName 42 colorantRequestedIndex 42 colorantRequestedName 43 colorantConsumedIndex 43 colorantConsumedName 43 Time attributes (set by server or device) 43 jobSubmissionToServerDateAndTime 43 jobSubmissionToDeviceDateAndTime 43 jobSubmissionToDeviceTimeStamp 43 jobStartedBeingHeldTimeStamp 43 jobStartedProcessingDateAndTime 43 jobStartedProcessingTimeStamp 44 jobCompletedDateAndTime 44 jobCompletedTimeStamp 44 jobProcessingCPUTime 44 JmJobServiceTypesTC - bit encoded job service type definitions 44 JmJobStateReasons1TC - additional information about job states 45 JmJobStateReasons2TC - More additional information about job states 48 JmJobStateReasons3TC - More additional information about job states 53 JmJobStateReasons4TC - More additional information about job states 54 The General Group (Mandatory) 56 jmGeneralNumberOfActiveJobs 56 jmGeneralOldestActiveJobIndex 57 jmGeneralNewestActiveJobIndex 57 jmGeneralJobPersistence 58 jmGeneralAttributePersistence 58 jmGeneralJobSetName 58 Bergman, Hastings, Isaacson, Lewis [Page 4] Job Monitoring MIB, V0.81 April 24, 1997 The Job ID Group (Mandatory) 59 jmJobSubmissionIDIndex 60 jmJobSetIndex 61 jmJobIndex 61 The Job State Group (Mandatory) 61 jmJobState 62 jmJobStateKOctetsCompleted 63 jmJobStateImpressionsCompleted 63 jmJobStateAssociatedValue 63 The Attribute Group (Mandatory) 64 jmAttributeTypeIndex 65 jmAttributeInstanceIndex 66 jmAttributeValueAsInteger 66 jmAttributeValueAsOctets 67 12. JOB LIFE CYCLE 70 13. BIBLIOGRAPHY 71 14. AUTHOR'S ADDRESSES 71 15. INDEX 74 Bergman, Hastings, Isaacson, Lewis [Page 5] Job Monitoring MIB, V0.81 April 24, 1997 Job Monitoring MIB 1. Introduction The Job Monitoring MIB consists of a 5-object General Group, a 2-object Job Submission ID Group, a 4-object Job State Group, and a 2-object Attribute Group. Each group is a table. The General Group contains general information that applies to all jobs in a job set. The Job Submission ID table maps the job submission ID that the client uses to identify a job to the jmJobIndex that the Job Monitoring Agent uses to identify jobs in the Job State and Attribute tables. The Job State table contains the job state and copies of three salient attributes for each job's current state. The Attribute table consists of multiple entries per job that specify (1) job and document identification and parameters, (2) requested resources, and (3) consumed resources during and after job processing/printing. The Job Monitoring MIB is intended to be instrumented by an agent within a printer or the first server closest to the printer, where the printer is either directly connected to the server only or the printer does not contain the job monitoring MIB agent. It is recommended that implementations place the SNMP agent as close as possible to the processing of the print job. This MIB applies to printers with and without spooling capabilities. This MIB is designed to be compatible with most current commonly-used job submission protocols. In most environments that support high function job submission/job control protocols, like ISO DPA[2], those protocols would be used to monitor and manage print jobs rather than using the Job Monitoring MIB. 1.1 Types of Information in the MIB The job MIB is intended to provide the following information for the indicated Role Models in the Printer MIB[1] (Refer to RFC 1759, Appendix D - Roles of Users). User: Provide the ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take. Provide the ability to identify the current status of the job (user queries). Provide a timely notification that the job has completed and where it can be found. Provide error and diagnostic information for jobs that did not successfully complete. Operator: Provide a presentation of the state of all the jobs in the print system. Bergman, Hastings, Isaacson, Lewis [Page 6] Job Monitoring MIB, V0.81 April 24, 1997 Provide the ability to identify the user that submitted the print job. Provide the ability to identify the resources required by each job. Provide the ability to define which physical printers are candidates for the print job. Provide some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates. Capacity Planner: Provide the ability to determine printer utilization as a function of time. Provide the ability to determine how long jobs wait before starting to print. Accountant: Provide information to allow the creation of a record of resources consumed and printer usage data for charging users or groups for resources consumed. Provide information to allow the prediction of consumable usage and resource need. The MIB supports printers that can contain more than one job at a time, but still be usable for low end printers that only contain a single job at a time. In particular, the MIB supports the needs of Windows and other PC environments for managing low-end networked devices without unnecessary overhead or complexity, while also providing for higher end systems and devices. 1.2 Types of Job Monitoring Applications The Job Monitoring MIB is designed for the following types of monitoring applications: 1.monitor a single job starting when the job is submitted and finishing a defined period after the job completes. The Job Submission ID table provides the map to find the specific job to be monitored. 2.monitor all active of the jobs in a queue, which is generalized to a job set. End users may use such a program when selecting a least busy printer, so the MIB is designed for such a program to start up quickly and find the information needed quickly without having to read all (completed) jobs in order to find the active jobs. System operators may also use such a program in which case it would be running for a long period of time and may also be interested in the Bergman, Hastings, Isaacson, Lewis [Page 7] Job Monitoring MIB, V0.81 April 24, 1997 jobs that have completed. Finally such a program may be co-located with the printer to provide an enhanced console capability. 3.collect resource usage for accounting or system utilization purposes that copy the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job-retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed). Such a program is expected to keep a shadow copy of the entire Job Attribute table including canceled and completed jobs which the program updates on each polling cycle. Such a program polls at the rate of the persistence of the Attribute table. The design is not optimized to help such an application determine which jobs are completed or canceled. Instead, the application shall query each job that the application's shadow copy shows was not complete or canceled at the previous poll cycle to see if it is now complete or canceled, plus any new jobs that have been submitted. The MIB provides a set of objects that represent a compatible subset of job and document attributes of the ISO DPA standard[2], so that coherence is maintained between the two protocols and information presented to end users and system operators. However, the job monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI)[4], as well as with ones that do implement ISO DPA. So nothing in the job monitoring MIB shall require implementation of the ISO DPA protocol. The MIB is designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs as an augmentation to this MIB. 2. Terminology and Job Model This section defines the terms that are used in this specification and the general model for jobs. NOTE - Existing systems use conflicting terms, so these terms are drawn from the ISO 10175 Document Printing Application (DPA) standard[2]. For example, PostScript systems use the term session for what we call a job in this specification and the term job to mean what we call a document in this paper. PJL systems use the term .. A job is a unit of work whose results are expected together without interjection of unrelated results. A client is able to specify job instructions that apply to the job as a whole. Proscriptive instructions specify how, when, and where the job is to be printed. Descriptive instructions describe the job. A job contains one or more documents. A job set is a set of jobs that are queued and scheduled together according to a specified scheduling algorithm for a specified device or set of devices. For implementations that embed the SNMP agent in the device, the MIB job set normally represents all the jobs known to the device, so that the implementation only implements a single job set Bergman, Hastings, Isaacson, Lewis [Page 8] Job Monitoring MIB, V0.81 April 24, 1997 which may be identified with a hard-coded value 1. If the SNMP agent is implemented in a server that controls one or more devices, each MIB job set represents a job queue for (1) a specific device or (2) set of devices, if the server uses a single queue to load balance between several devices. Each job set is disjoint; no job shall be represented in more than one MIB job set. A document is a sub-section within a job. A document contains print data and document instructions that apply to just the document. The client is able to specify document instructions separately for each document in a job. Proscriptive instructions specify how the document is to be processed and printed by the server. Descriptive instructions describe the document. Server implementation of more than one document per job is optional. A client is the network entity that end users use to submit jobs to spoolers, servers, or printers and other devices, depending on the configuration, using any job submission protocol. A server is a network entity that accepts jobs from clients and in turn submits the jobs to printers and other devices. A server may be a printer supervisor control program, or a print spooler. A device is a hardware entity that (1) interfaces to humans in human perceptible means, such as produces marks on paper, scans marks on paper to produce an electronic representations, or writes CD-ROMs or (2) interfaces to a network, such as sends FAX data to another FAX device. A printer is a device that puts marks on media. A supervisor is a server that contains a control program that controls a printer or other device. A supervisor is a client to the printer or other device. A spooler is a server that accepts jobs, spools the data, and decides when and on which printer to print the job. A spooler is a client to a printer or a printer supervisor, depending on implementation. Spooling is the act of a device or server of (1) accepting jobs and (2) writing the job's attributes and document data on to secondary storage. Queuing is the act of a device or server of ordering (queuing) the jobs for the purposes of scheduling the jobs to be processed. A monitor or job monitoring application is the network entity that End Users, System Operators, Accountants, Asset Managers, and Capacity Planners use to monitor jobs using SNMP. A monitor may be either a separate application or may be part of the client that also submits jobs. An agent is the network entity that accepts SNMP requests from a monitor and implements the Job Monitoring MIB. A proxy is an agent that acts as a concentrator for one or more other agents by accepting SNMP operations on the behalf of one or more other Bergman, Hastings, Isaacson, Lewis [Page 9] Job Monitoring MIB, V0.81 April 24, 1997 agents, forwarding them on to those other agents, gathering responses from those other agents and returning them to the original requesting monitor. A user is a person that uses a client or a monitor. An end user is a user that uses a client to submit a print job. A system operator is a user that uses a monitor to monitor the system and carries out tasks to keep the system running. A system administrator is a user that specifies policy for the system. A job instruction is an instruction specifying how, when, or where the job is to be processed. Job instructions may be passed in the job submission protocol or may be embedded in the document data or a combination depending on the job submission protocol and implementation. A document instruction is an instruction specifying how to process the document. Document instructions may be passed in the job submission protocol separate from the actual document data, or may be embedded in the document data or a combination, depending on the job submission protocol and implementation. An SNMP information object is a name, value-pair that specifies an action, a status, or a condition in an SNMP MIB. Objects are identified in SNMP by an OBJECT IDENTIFIER. An attribute is a name, value-pair that specifies an instruction, a status, or a condition of a job or a document that has been submitted to a server or device. A particular attribute need not be present in each job instance. In other words, attributes are present in a job instance only when there is a need to express the value, either because (1) the client supplied a value in the job submission protocol, (2) the document data contained an embedded attribute, or (3) the server or device supplied a default value. An agent shall represent an attribute as an entry (row) in the attribute table in this MIB in which entries are present only when necessary. Attributes are identified in this MIB by an enum.. Job monitoring using SNMP is (1) identifying jobs within the serial streams of data being processed by the server, printer or other devices, (2) creating "rows" in the job table for each job, and (3) recording information, known by the agent, about the processing of the job in that "row". Job accounting is recording what happens to the job during the processing and printing of the job. 3. System Configurations for the Job Monitoring MIB This section enumerates the three configurations for which the Job Monitoring MIB is intended to be used. To simplify the pictures, the devices are shown as printers. See Goals section. Bergman, Hastings, Isaacson, Lewis [Page 10] Job Monitoring MIB, V0.81 April 24, 1997 The diagram in the Printer MIB[1] entitled: "One Printer's View of the Network" is assumed for this MIB as well. Please refer to that diagram to aid in understand the following system configurations. 3.1 Configuration 1 - client-printer In the client-printer configuration, the client(s) submit jobs directly to the printer, either by some direct connect, or by network connection. The client-printer configuration can accommodate multiple job submitting clients in either of two ways: 1.if each client relinquishes control of the Print Job Delivery Channel after each job (or after a number of jobs) 2.if the printer supports more than one Print Job Delivery Channel The job submitting client and/or monitoring application monitor jobs by communicating directly with an agent that is part of the printer. The agent in the printer shall keep the job in the Job Monitoring MIB as long as the job is in the Printer, and longer in order to implement the completed state in which monitoring programs can copy out the accounting data from the Job Monitoring MIB. all end-user ######## SNMP query +-------+ +--------+ ---- job submission |monitor| | client | +---#---+ +--#--+--+ # # | # ############ | # # | +==+===#=#=+==+ | | | agent | | | | +-------+ | | | PRINTER <--------+ | | Print Job Delivery Channel | | +=============+ Figure 1 - Configuration 1 - client-printer - agent in the printer The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 1): 1.Multiple clients may submit jobs to a printer. 2.Multiple clients may monitor a printer. 3.Multiple monitors may monitor a printer. 4.A client may submit jobs to multiple printers. 5.A monitor may monitor multiple printers. 3.2 Configuration 2 - client-server-printer - agent in the server In the client-server-printer configuration 2, the client(s) submit jobs to an intermediate server by some network connection, not directly to Bergman, Hastings, Isaacson, Lewis [Page 11] Job Monitoring MIB, V0.81 April 24, 1997 the printer. While configuration 2 is included, the design center for this MIB is configurations 1 and 3, The job submitting client and/or monitoring application monitor job by communicating directly with: 1.a Job Monitoring MIB agent that is part of the server (or a front for the server) There is no SNMP Job Monitoring MIB agent in the printer in configuration 2, at least that the client or monitor are aware. In this configuration, the agent shall return the current values of the objects in the Job Monitoring MIB both for jobs the server keeps and jobs that the server has submitted to the printer. In configuration 2, the server keeps a copy of the job during the time that the server has submitted the job to the printer. Only some time after the printer completes the job, shall the server remove the representation of the job from the Job Monitoring MIB in the server. The agent need not access the printer, except when a monitor queries the agent using an SNMP Get for an object in the Job Monitoring MIB. Or the agent can subscribe to the notification events that the printer generates and keep the Job Monitoring MIB update to date. The agent in the server shall keep the job in the Job Monitoring MIB as long as the job is in the Printer, and longer in order to implement the completed state in which monitoring programs can copy out the accounting data from the Job Monitoring MIB. all end-user +-------+ +----------+ |monitor| | client | ######## SNMP query +---+---# +---#----+-+ **** non-SNMP cntrl # # | ---- job submission # # | # # | #=====#=+==v==+ | agent | | +-------+ | | server | +----+-----+--+ control * | ********** | * | +========v====+ | | | | | | | | PRINTER <---------+ | | Print Job Delivery Channel | | +=============+ Figure 2 - Configuration 2 - client-server-printer - agent in the server The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 2): 1.Multiple clients may submit jobs to a server. Bergman, Hastings, Isaacson, Lewis [Page 12] Job Monitoring MIB, V0.81 April 24, 1997 2.Multiple clients may monitor a server. 3.Multiple monitors may monitor a server. 4.A client may submit jobs to multiple servers. 5.A monitor may monitor multiple servers. 6.Multiple servers may submit jobs to a printer. 7.Multiple servers may control a printer. 3.3 Configuration 3 - client-server-printer - client monitors printer agent and server In the client-server-printer configuration 3, the client(s) submit jobs to an intermediate server by some network connection, not directly to the printer. The job submitting client and/or monitoring application monitor jobs by communicating directly with: 1.the server using some protocol to monitor jobs in the server that does not contain the Job Monitoring MIB AND 2.a Job Monitoring MIB agent that is part of the printer to monitor jobs after the server passes the jobs to the printer. In such configurations, the server deletes its copy of the job from the server after submitting the job to the printer usually almost immediately (before the job does much processing, if any). There is no SNMP Job Monitoring MIB agent in the server in configuration 3, at least that the client or monitor are aware. In this configuration, the agent (in the printer) shall keep the values of the objects in the Job Monitoring MIB that the agent implements updated for a job that the server has submitted to the printer. The agent shall obtain information about the jobs submitted to the printer from the server (either in the job submission protocol, in the document data, or by direct query of the server), in order to populate some of the objects the Job Monitoring MIB in the printer. The agent in the printer shall keep the job in the Job Monitoring MIB as long as the job is in the Printer, and longer in order to implement the completed state in which monitoring programs can copy out the accounting data from the Job Monitoring MIB. all end-user +-------+ +----------+ |monitor| | client | ######## SNMP query +---+---* +---*----+-+ **** non-SNMP query # * * | ---- job submission # * * | # * * | # *=====v====v==+ # | | # | server | # | | # +----#-----+--+ # optional# | # ########## | Bergman, Hastings, Isaacson, Lewis [Page 13] Job Monitoring MIB, V0.81 April 24, 1997 # # | +==+=v===v=+==+ | | | agent | | | | +-------+ | | | PRINTER <---------+ | | Print Job Delivery Channel | | +=============+ Figure 3 - Configuration 3 - client-server-printer - client monitors printer agent and server The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 3): 1.Multiple clients may submit jobs to a server. 2.Multiple clients may monitor a server. 3.Multiple monitors may monitor a server. 4.A client may submit jobs to multiple servers. 5.A monitor may monitor multiple servers. 6.Multiple servers may submit jobs to a printer. 7.Multiple servers may control a printer. 4. Conformance Considerations In order to achieve interoperability between job monitoring applications and job monitoring agents, this specification includes the conformance requirements for both monitoring applications and agents. 4.1 Conformance Terminology This specification uses the verbs: "shall", "should", "may", and "need not" to specify conformance requirements as follows: . "shall": indicates an action that the subject of the sentence must implement in order to claim conformance to this specification . "may": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification, in other words that action is an implementation option . "need not": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification. The verb "need not" is used instead of "may not", since "may not" sounds like a prohibition. . "should": indicates an action that is recommended for the subject of the sentence to implement, but is not required, in order to claim conformance to this specification. 4.2 Agent Conformance Requirements A conforming agent: Bergman, Hastings, Isaacson, Lewis [Page 14] Job Monitoring MIB, V0.81 April 24, 1997 1.shall implement all mandatory groups and attributes in this specification. 2.shall implement each conditionally mandatory attributes, if the server or device that the agent is instrumenting has the feature represented by the conditionally mandatory attribute.. 3.need not implement both forms of a time attribute if it implements a time attribute and is recommended not to provide both forms for a particular time attribute. See page 43. NOTE - This MIB, like the Printer MIB, is written following the subset of SMIv2 that can be supported by SMIv1 and SNMPv1 implementations. 4.2.1 MIB II System Group objects The Job Monitoring MIB agent shall implement all objects in the system group of MIB-II (RFC 1213)[5], whether the Printer MIB[1] is implemented or not. 4.2.2 MIB II Interface Group objects The Job Monitoring MIB agent shall implement all objects in the Interfaces Group of MIB-II (RFC 1213)[5], whether the Printer MIB[1] is implemented or not. 4.2.3 Printer MIB objects If the agent is instrumenting a device that is a printer, the agent shall implement all of the mandatory objects in the Printer MIB[1] and all the objects in other MIBs that conformance to the Printer MIB requires, such as the Host Resources MIB (RFC 1514)[6]. If the agent is instrumenting a server that controls one or more networked printers, the agent need not implement the Printer MIB and need not implement the Host Resources MIB. 4.3 Job Monitoring Application Conformance Requirements A conforming job monitoring application: 1.shall accept all objects in all mandatory groups and all mandatory and conditionally mandatory attributes that are required to be implemented by an agent according to Section 4.2 and shall either present them to the user or ignore them. 2.shall accept all enum and bit values specified in this standard and additional ones that may be registered with IANA and shall either present them to the user or ignore them. In particular, a conforming job monitoring application shall not malfunction when receiving any standard or registered enum or bit values. See Section 7 entitled "IANA Considerations" on page 17. Bergman, Hastings, Isaacson, Lewis [Page 15] Job Monitoring MIB, V0.81 April 24, 1997 3.shall accept either form of time attribute, if it supports a time attribute, since agents are free to implement either time form. See page 43. 5. Job Identification There are a number of attributes that permit a user, operator or system administrator to identify jobs of interest, such as jobOwner, jobName, etc. In addition, there is a Job Submission ID object that allows a monitoring application to quickly locate and identify a particular job of interest that was submitted from a particular client by the user invoking the monitoring application. The Job Monitoring MIB needs to provide for identification of the job at both sides of the job submission process. The primary identification point is the client side. The Job Submission ID allows the monitoring application to identify the job of interest from all the jobs currently "known" by the server or device. The Job Submission ID can be assigned by either the client's local system or a downstream server or device. The point of assignment will be determined by the job submission protocol in use. The server/device-side identifier, called the jmJobIndex object, will be assigned by the server or device that accepts the jobs from submitting clients. The MIB agent shall use the job identifier assigned by the server or device to the job as the value of the jmJobIndex object that defines the table rows (there are multiple tables) that contain the information relating to the job. This object allows the interested party to obtain all objects desired that relate to this job. The MIB provides a mapping table that maps each Job Submission ID to the corresponding jmJobIndex value, so that an application can determine the correct value for the jmJobIndex value for the job of interest in a single Get operation. See the jmJobIDGroup on page 59. The jobName attribute provides a name that the user supplies an a job attribute with the job. The jobName attribute is not necessarily unique, even for one user, let alone across users. 6. Internationalization Considerations There are a number of objects in this MIB that are represented as coded character sets. The data type for such objects is OCTET STRING. Such objects could be in different coded character sets and could be localized in the language and country, i.e., could be localized. However, for the Job Monitoring MIB, most of the objects are supplied as job attributes by the client that submits the job to the server or device and so are represented in the coded character set specified by that client. Therefore, the agent is not able to provide for different representations depending on the locale of the server, device, or user of the job monitoring application. The only exception is job submission protocols that pass job or document attributes as OBJECT IDENTIFIERS or enums. For those job and document attributes, the agent shall represent the corresponding objects in the Job Monitoring MIB as coded character sets in the current (default) locale of the server or printer as established by the system administrator or the implementation. Bergman, Hastings, Isaacson, Lewis [Page 16] Job Monitoring MIB, V0.81 April 24, 1997 For simplicity, this specification assumes that the clients, job monitoring applications, servers, and devices are all running in the same locale. However, this specification allows them to run in any locale, including locales that use two-octet coded character sets, such as ISO 10646 (Unicode). Job monitors applications are expected to understand the coded character set of the client (and job), server, or device. No special means is provided for the monitor to discover the coded character set used by jobs or by the server or device. This specification does not contain an object that indicates what locale the server or device is running in, let alone contain an object to control what locale the agent is to use to represent coded character set objects. This MIB also contains objects that are represented using the DateAndTime textual convention from SNMPv2-TC (RFC 1903). The job management application shall display such objects in the locale of the user running the monitoring application. 7. IANA Considerations During the development of this standard, the Printer Working Group (PWG) working with IANA will register additional enums while the standard is in the proposed and draft states according to the procedures described in this section. IANA will handle registration of additional enums after this standard is approved in cooperation with an IANA-appointed registration editor from the PWG according to the procedures described in this section: 7.1 IANA Registration of enums This specification uses textual conventions to define enumerated values (enums) and bit values. Enumerations (enums) and bit values are sets of symbolic values defined for use with one or more objects or attributes. All enumeration sets and bit value sets are assigned a symbolic data type name (textual convention). As a convention the symbolic name ends in "TC" for textual convention. These enumerations are defined at the beginning of the MIB module specification. This working group has defined several type of enumerations for use in the Job Monitoring MIB and the Printer MIB[1]. These types differ in the method employed to control the addition of new enumerations. Throughout this document, references to "type n enum", where n can be 1, 2 or 3 can be found in the various tables. The definitions of these types of enumerations are: 7.1.1 Type 1 enumerations Type 1 enumeration: All the values are defined in the Job Monitoring MIB specification (RFC for the Job Monitoring MIB). Additional enumerated values require a new RFC. NOTE - There are no type 1 enums in the current draft. Bergman, Hastings, Isaacson, Lewis [Page 17] Job Monitoring MIB, V0.81 April 24, 1997 7.1.2 Type 2 enumerations Type 2 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered after review by this working group. The initial versions of the MIB will contain the values registered so far. After the MIB is approved, additional values will be registered through IANA after approval by this working group. The following type 2 enums are contained in the current draft : 1.JmTimeStampTC 2.JmFinishingTC 3.JmPrintQualityTC 4.JmTonerEconomyTC 5.JmTonerDensityTC 6.JmMediumTypeTC 7.JmJobStateTC 8.JmAttributeTypeTC 7.1.3 Type 3 enumeration Type 3 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered without working group review. The initial versions of the MIB will contain the values registered so far. After the MIB is approved, additional values will be registered through IANA without approval by this working group. NOTE - There are no type 3 enums in the current draft. 7.2 IANA Registration of type 2 bit values This draft contains the following type 2 bit value textual-conventions: 1.JmJobServiceTypesTC 2.JmJobStateReasons1TC 3.JmJobStateReasons2TC 4.JmJobStateReasons3TC 5.JmJobStateReasons4TC These textual-conventions are defined as bits in an Integer so that they may be used with SNMPv1 SMI.. The jobStateReasonsn (n=1..4) attributes are defined as bit values using the JmJobStateReasonsnTC textual- convention. The registration of JmJobServiceTypesTC and JmJobStateReasonsnTC bit values shall follow the procedures for a type 2 enum as specified in Section 7.1.2. 7.3 IANA Registration of Job Submission Id Formats In addition to enums and bit values, this specification assigns numbers to various job submission ID formats. See jmJobSubmissionIDIndex on page 60. The registration of jmJobSubmissionIDIndex format numbers shall follow the procedures for a type 2 enum as specified in Section 7.1.2. Bergman, Hastings, Isaacson, Lewis [Page 18] Job Monitoring MIB, V0.81 April 24, 1997 8. Security Considerations 8.1 Read-Write objects All objects are read-only greatly simplifying the security considerations. If another MIB augments this MIB, that MIB might allow objects in this MIB to be modified. However, that MIB shall have to support the required access control in order to achieve security, not this MIB. 8.2 Read-Only Objects In Other User's Jobs The security policy of some sites may be that unprivileged users can only get the objects from jobs that they submitted, plus a few minimal objects from other jobs, such as the jobKOctetsRequested and jobKOctetsCompleted attributes, so that a user can tell how busy a printer is. Other sites might allow all unprivileged users to see all objects of all jobs. It is up to the agent to implement any such restrictions based on the identification of the user making the SNMP request. This MIB does not require, nor does it specify how, such restrictions would be implemented. A monitoring application should enforce the site security policy with respect to returning information to an unprivileged end user that is using the monitoring application to monitor jobs that do not belong to that user, i.e., the jobOwner attribute in the jmAttributeTable does not match the user's user name. See the JmAttributeTypeTC textual convention on page 41 and the jmAttributeTable. An operator is a privileged user that would be able to see all objects of all jobs, independent of the policy for unprivileged users. 9. Returning Objects With No Value In Mandatory Groups If an object in a mandatory group does not have an instrumented value for a particular job submission protocol or the job submitting client did not supply a value (and the accepting server or device does not supply a default), this MIB requires that the agent shall follow the normal SNMP practice of returning a distinguished value, such as a zero- length string, an unknown(2) value for an enum, or a (-2) for an integer value. 10. Notification and Traps This MIB does not specify any traps. For simplicity, management applications are expected to poll for status. The resulting network traffic is not expected to be significant. 11. MIB specification The following pages constitute the actual Job Monitoring MIB. Bergman, Hastings, Isaacson, Lewis [Page 19] Job Monitoring MIB, V0.81 April 24, 1997 Job-Monitoring-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- The following textual-conventions are needed -- to implement certain attributes, but are not -- needed to compile this MIB. They are -- provided here for convenience: -- DateAndTime FROM SNMPv2-TC -- PrtAlertCodeTC, PrtInterpreterLangFamilyTC FROM Printer-MIB -- Use the experimental (54) OID assigned to the Printer MIB[1] before -- it was published as RFC 1759. -- Upon publication of the Job Monitoring MIB as an RFC, delete this -- comment and the line following this comment and change the -- reference of { temp 104 } (below) to { mib-2 X }. -- This will result in changing: -- 1 3 6 1 3 54 jobmonMIB(105) to: -- 1 3 6 1 2 1 jobmonMIB(X) -- This will make it easier to translate prototypes to -- the standard namespace because the lengths of the OIDs won't -- change. temp OBJECT IDENTIFIER ::= { experimental 54 } jobmonMIB MODULE-IDENTITY LAST-UPDATED "9704240000Z" ORGANIZATION "IETF Printer MIB Working Group" CONTACT-INFO "Tom Hastings Postal: Xerox Corp. Mail stop ESAE-231 701 S. Aviation Blvd. El Segundo, CA 90245 Tel: (301)333-6413 Fax: (301)333-5514 E-mail: hastings@cp10.es.xerox.com" DESCRIPTION "The MIB module for monitoring job in servers, printers, and other devices. File: jmp-mib.doc, .pdf, .txt, .mib Version: 0.81" ::= { temp 105 } -- Textual conventions for this MIB module JmTimeStampTC ::= TEXTUAL-CONVENTION Bergman, Hastings, Isaacson, Lewis [Page 20] Job Monitoring MIB, V0.81 April 24, 1997 STATUS current DESCRIPTION "The simple time at which an event took place. The units shall be in seconds since the system was booted. NOTE - JmTimeStampTC is defined in units of seconds, rather than 100ths of seconds, so as to be simpler for agents to implement (even if they have to implement the 100ths of a second to comply with implementing sysUpTime in MIB-II[5].) NOTE - JmTimeStampTC is defined as an Integer32 so that it can be used as a value of an attribute, i.e., as a value of the jmAttributeValueAsInteger object (see page 66). The TimeStamp textual-convention defined in SMNPv2-TC is defined as an APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32, so cannot be used in this MIB as one of the values of jmAttributeValueAsInteger." SYNTAX INTEGER(0..2147483647) JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source platform type that can submit jobs to servers or devices in any of the 3 configurations." -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { other(1), unknown(2), sptUNIX(3), -- UNIX(tm) sptOS2(4), -- OS/2 sptPCDOS(5), -- DOS sptNT(6), -- NT sptMVS(7), -- MVS sptVM(8), -- VM sptOS400(9), -- OS/400 sptVMS(10), -- VMS sptWindows95(11), -- Windows95 sptNetWare(33) -- NetWare } JmFinishingTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of finishing." Bergman, Hastings, Isaacson, Lewis [Page 21] Job Monitoring MIB, V0.81 April 24, 1997 -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { other(1), -- Some other finishing besides one of the specified or -- registered values. unknown(2), -- The finishing is unknown. none(3), -- Perform no finishing. staple(4), -- Bind the document(s) with one or more staples. The exact -- number and placement of the staples is site-defined. stapleTopLeft(5), -- Place one or more staples on the top left corner of the -- document(s). stapleBottomLeft(6), -- Place one or more staples on the bottom left corner of -- the document(s). stapleTopRight(7), -- Place one or more staples on the top right corner of the -- document(s). stapleBottomRight(8), -- Place one or more staples on the bottom right corner of -- the document(s). saddleStitch(9), -- Bind the document(s) with one or more staples (wire -- stitches) along the middle fold. The exact number and -- placement of the stitches is site-defined. edgeStitch(10), -- Bind the document(s) with one or more staples (wire -- stitches) along one edge. The exact number and -- placement of the staples is site-defined. punch(11), -- This value indicates that holes are required in the -- finished document. The exact number and placement of the -- holes is site-defined The punch specification may be -- satisfied (in a site- and implementation-specific -- manner) either by drilling/punching, or by substituting -- pre-drilled media. cover(12), -- This value is specified when it is desired to select a -- non-printed (or pre-printed) cover for the document. -- This does not supplant the specification of a printed -- cover (on cover stock medium) by the document itself. Bergman, Hastings, Isaacson, Lewis [Page 22] Job Monitoring MIB, V0.81 April 24, 1997 bind(13) -- This value indicates that a binding is to be applied to -- the document; the type and placement of the binding is -- site-defined. } JmPrintQualityTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Print quality settings." -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { other(1), -- Not one of the specified or registered values. unknown(2), -- The actual value is unknown. draft(3), -- Lowest quality available on the printer. normal(4), -- Normal or intermediate quality on the printer. high(5) -- Highest quality available on the printer. } JmTonerEconomyTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Toner economy settings." -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { off(0), -- Off. Normal. Use full toner. on(1) -- On. Use less toner than normal. } JmMediumTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the type of medium." -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { Bergman, Hastings, Isaacson, Lewis [Page 23] Job Monitoring MIB, V0.81 April 24, 1997 other(1), -- The type is neither one of the values listed in this -- specification nor a registered value. unknown(2), -- The type is not known. stationery(3), -- Separately cut sheets of an opaque material. transparency(4), -- Separately cut sheets of a transparent material. envelope(5), -- Envelopes that can be used for conventional mailing -- purposes. envelopePlain(6), -- Envelopes that are not preprinted and have no windows. envelopeWindow(7), -- Envelopes that have windows for addressing purposes. continuousLong(8), -- Continuously connected sheets of an opaque material -- connected along the long edge. continuousShort(9), -- Continuously connected sheets of an opaque material -- connected along the short edge. tabStock(10), -- Media with tabs. multiPartForm(11), -- Form medium composed of multiple layers not pre-attached -- to one another; each sheet may be drawn separately from -- an input source. labels(12), -- Label-stock. multiLayer(13) -- Form medium composed of multiple layers which are pre- -- attached to one another, e.g. for use with impact -- printers. } JmJobStateTC ::= TEXTUAL-CONVENTION Bergman, Hastings, Isaacson, Lewis [Page 24] Job Monitoring MIB, V0.81 April 24, 1997 STATUS current DESCRIPTION "The current state of the job (pending, processing, held, etc.) Management applications shall be prepared to receive all the standard job states. Agents instrumenting servers and devices are not required to generate all job states, only those that are indicated as 'mandatory' in the enum definitions below. The remaining job states are 'conditionally mandatory', i.e., an agent for a server or device shall implement each of the remaining states if server or device jobs have states with the same semantics. See Section 12 entitled 'Job Life Cycle' on page 70 for additional job state semantics, legal job state transitions, and implementation considerations. Companion textual conventions (JmJobStateReasonsnTC, n=1..4) and corresponding attributes (jobStateReasonsn) provide additional information about job states. While the job states cannot be added to without impacting deployed clients, it is the intent that additional JmJobStateReasonsnTC enums can be defined without impacting deployed clients that take actions upon receiving job state values. In other words, the JmJobStateReasonsnTC TCs are intended to be extensible. See page 45. The following job state standard values are defined:" -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { other(1), -- The job state is not one of the defined states. unknown(2), -- The job state is not known, or is indeterminate. held(3), -- The job is not yet a candidate for processing for any -- number of reasons. The reasons are represented as bits -- in the jobStateReasons1 attribute. Some reasons are used -- in other states to give added information about the job -- state. See the JmJobStateReasons1TC textual convention -- for the specification of each reason and in which states -- the reasons may be used. pending(4), -- The job is a candidate for processing, but is not yet -- processing. processing(5), -- mandatory -- The job is using one or more document transforms which -- include purely software processes, such as interpreting a -- PDL, and hardware devices, but is not yet making marks on -- a medium. -- -- If an implementation does not distinguish between Bergman, Hastings, Isaacson, Lewis [Page 25] Job Monitoring MIB, V0.81 April 24, 1997 -- processing and printing, then the processing state shall -- be implemented. printing(6), -- The job is printing, i.e., making marks on a medium. -- -- If an implementation does not distinguish between -- processing and printing, then the processing state shall -- be implemented. needsAttention(7), -- mandatory -- The job is using one or more devices, but has encountered -- a problem with at least one device that requires human -- intervention before the job can continue using that -- device. Examples include running out of paper or a paper -- jam. -- -- Usually devices indicate their condition in human -- readable form locally at the device. The management -- application can obtain more complete device status -- remotely by querying the appropriate device MIB using the -- job's deviceIndex attribute. canceled(8), -- mandatory -- The job is in the process of being terminated by the -- server or device or has completed terminating the job, -- either because the client canceled the job or because a -- serious problem was encountered by a document transform -- while processing the job. The job's jobStateReasons1 -- attribute shall contain the reasons that the job was -- canceled. The job shall remain in the canceled state for -- the same period of time as if the job had completed, -- before transiting to the unknown state. See the -- completed state description. completed(9) -- mandatory -- The job has (1) completed after processing/printing and -- all of the media have been successfully stacked in the -- output bin(s). -- -- The job has completed successfully or with warnings or -- errors. The job's jobStateReasons1 attribute shall -- contain the reasons that the job has entered the -- completed state. -- -- The length of time that a job may be in the completed -- state, before transitioning to unknown, is specified by -- the value of the jmGeneralJobPersistence object. In -- addition, the agent shall maintain all of the attributes -- in the jmAttributeTable for at least the time specified -- in the jmGeneralAttributePersistence object, so that a -- management application accounting program can copy all -- the attributes to an accounting log. } Bergman, Hastings, Isaacson, Lewis [Page 26] Job Monitoring MIB, V0.81 April 24, 1997 JmAttributeTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the attribute. Some attributes represent information about a job, such as a file-name, or a document-name, or submission-time or completion time. Other attributes represent resources required, e.g., a medium or a colorant, etc. to process the job before the job start processing OR to indicate the amount of the resource that is being consumed while the job is processing, e.g., pages completed or impressions completed. If both a required and a consumed value of a resource is needed, this specification assigns two separate attribute enums in the textual convention. Datatypes The datatype of each attribute is indicated on the first line of the description. Some attributes have several different data type representations. Each such representation is considered a separate attribute and is assigned a separate name and enum value. For these attributes, the name of the datatype is the last part of the name of the attribute. Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes Most attributes shall have only one row per job. However, a few attributes can have multiple values per job or even per document, where each value is a separate row in the jmAttributeTable. Unless indicated with 'MULTI-ROW:' in JmAttributeTypeTC, an agent shall ensure that each attribute item occurs only once in the jmAttributeTable for a job. Attributes that may appear multiple times in the jmAttributeTable for a job are indicated with 'MULTI-ROW:' in their specification in the JmAttributeTypeTC. However, such attribute items shall not contain duplicates for 'intensive' (as opposed to 'extensive') attributes. For example, each documentFormatType attribute entry shall appear in the jmAttributeTable only once for a job since the interpreter language is an intensive attribute item, even though the job has a number of documents that all use the same PDL. As another example of an intensive attribute that can have multiple entries, if a document or job uses multiple types of media, there shall be only one row in the jmAttributeTable for each media type, not one row for each document that uses that medium type. On the other hand, if a job contains two documents of the same name, there can be separate rows for the Bergman, Hastings, Isaacson, Lewis [Page 27] Job Monitoring MIB, V0.81 April 24, 1997 documentName attribute item with the same name, since a document name is an extensive attribute item. The specification indicates that the values need not be unique for such 'MULTI-ROW:' Value Represented As Integer Or Octets In the following definitions of the enums, each description indicates whether the value of the attribute shall be represented using the jmAttributeValueAsInteger or the jmAttributeValueAsOctets objects by the initial tag: 'INTEGER:' or 'OCTETS:', respectively. A very few attributes use both objects at the same time to represent a pair of values (mediumConsumed) and so have both tags. See the jmAttributeGroup on page 64 for the descriptions of these objects. For the attributes that do not use the jmAttributeValueAsInteger object (no 'INTEGER:' tag), the agent shall return the value (- 1) indicating other. For the attributes that do not use the jmAttributeValueAsOctets object (no 'OCTETS:' tag), the agent shall return a zero-length octet string. Attribute Creation An agent shall create a row in the jmAttributeTable for each attribute that is (1) supplied with a job when the job is accepted by a server or device or that (2) the server or device supplies as a default either when the job is accepted or later during processing. Consumption Attributes A number of attributes record consumption. Such attribute names end with the word 'Completed'. If the job has not yet consumed what that resource is metering, the agent either: (1) shall return the value 0 or (2) shall not add this attribute to the jmAttributeTable until the consumption begins. In the interests of brevity, the semantics for 0 is specified here and is not repeated for each xxxxYyyyCompleted attribute specification. Index Value Attributes A number of attributes are indexes in other tables. Such attribute names end with the word 'Index'. If the agent does not (yet) know the index value for a particular index attribute for a job, the agent either: (1) shall return the value 0 or (2) shall not add this attribute to the jmAttributeTable until the index value is known. In the interests of brevity, the semantics for 0 is specified here and is not repeated for each index attribute specification. Attribute Naming Conventions Bergman, Hastings, Isaacson, Lewis [Page 28] Job Monitoring MIB, V0.81 April 24, 1997 Attribute names often end in the data type, especially when there are more than one data type for the same information. Thus the suffixes are used: Name, Index, DateAndTime, TimeStamp, etc. NOTE: No attribute name exceeds 31 characters. Conformance of Attribute Implementation Some attributes are mandatory for conformance, and the rest are conditionally mandatory. An agent shall instrument any mandatory attribute. If the server or device does not provide access to the information about the mandatory attribute, the agent shall return the 'unknown' value. For attributes represented by a counting integer, the unknown value is (-2) and for attributes represented by an enum, the unknown value is (2), as in the Printer MIB[1]. An agent shall instrument any conditionally mandatory attribute if the server or device provides access to the information about the attribute to the agent. If the server or device does not provide access to the information about the conditionally mandatory attribute, the agent need not create the row in the jmAttributeTable. The mandatory attributes are the ones required to have copies in the jmJobStateTable and to remain in the jmAttributeTable longer. The mandatory attributes are: jobState(3) numberOfInterveningJobs(9) deviceAlertCode(10) jobKOctetsRequested(48) jobKOctetsCompleted(50) impressionsRequested(54) impressionsCompleted(55) outputBinName(35) The table of contents lists the attributes in order to help see the order of enum assignments which is the order that the GetNext operation can be used to get attributes. The standard attribute types defined so far are:" -- This is a type 2 enumeration. See Section 7.1 on page 17. SYNTAX INTEGER { -- jmAttributeTypeIndex Datatype -- Description - including 'OCTETS:' or 'INTEGER:' to -- specify whether the value shall be represented in the -- jmAttributeValueAsOctets or the jmAttributeValueAsInteger -- object, or both, respectively. other(1), -- Integer32(-2..2147483647) -- OR -- OCTET STRING(SIZE(0..63)) -- INTEGER: or OCTETS: An attribute that is not in the -- list and/or that has not been approved and registered Bergman, Hastings, Isaacson, Lewis [Page 29] Job Monitoring MIB, V0.81 April 24, 1997 -- with IANA. unknown(2), -- Integer32(-2..2147483647) -- OR -- OCTET STRING(SIZE(0..63)) -- INTEGER: or OCTETS: An attribute whose semantics are -- not known to the agent. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Job State attributes -- -- The following attributes specify the state of a job. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobState(3), -- JmJobStateTC (pg 24) -- INTEGER: The current state of the job (pending, -- processing, held, etc.). The final value for this -- attribute shall be either completed or canceled, before -- the agent removes the job from the table. -- -- Management applications shall be prepared to receive all -- the standard job states. Servers and devices are not -- required to generate all job states, only those which are -- appropriate for the particular implementation. -- -- NOTE - Companion textual conventions, -- JmJobStateReasonsnTC (n=1..4 - see page 45) and -- corresponding attributes (jobStateReasons1(5) - see page -- 31) provides additional information about job states. -- While the job states cannot be added to without impacting -- deployed clients, it is the intent that additional -- JmJobStateReasonsnTC enums can be defined without -- impacting deployed clients. jobStateAssociatedValue(4), -- Integer32(-2..2147483647) -- INTEGER: The value of the most relevant attribute -- associated with the job's current state. -- -- Which attribute depends on the job's current state (as -- specified by the value of the jmJobState/jobState -- object/attribute) as follows: -- -- jmJobState Associated Attribute Page -- /jobState -- -- held jobStartedBeingHeldTimeStamp(73) 43 -- pending numberOfInterveningJobs(9) 43 -- processing jobKOctetsRequested(48) 47 -- printing impressionsRequested(54) 49 -- needsAttention deviceAlertCode(10) 32 -- canceled impressionsCompleted(55) 41 -- completed outputBinName(35) 37 -- -- NOTE - The jobStateAssociatedValue attribute selects from Bergman, Hastings, Isaacson, Lewis [Page 30] Job Monitoring MIB, V0.81 April 24, 1997 -- amongst seven mandatory attributes that attribute that is -- most relevant to the job's current state. the -- jobStateAssociatedValue attribute is provided as an -- efficiency improvement, so that an application can obtain -- the most relevant attribute for each job's current state -- (1) without first having to determine the job's state or -- (2) having to request all seven mandatory attributes in -- the same GetNext operation that obtains the next job in -- the next conceptual row in the jmAttributeTable. jobStateReasons1(5), -- JmJobStateReasons1TC (pg 45) -- OCTETS: Additional information about the job's current -- state that augments the jmJobState/jobState -- object/attribute. The jobStateReasons1 attribute -- identifies the reason or reasons that the job is in the -- held, pending, processing, needsAttention, canceled, or -- completed state. The agent shall indicate the particular -- reason(s) by setting the value of the jobStateReasons1 -- attribute. When the job does not have any reasons for -- being in its current state, the agent shall set the value -- of the jobStateReasons1 attribute to 0. -- -- While the job states cannot be added to without impacting -- deployed clients, it is the intent that additional -- JmJobStateReasons1TC bit values can be defined without -- impacting deployed clients. In other words, the -- JmJobStateReasons1TC TC is intended to be extensible. -- -- Companion job state reasons TCs: JmJobStateReasons2TC, -- JmJobStateReasons3TC, JmJobStateReasons4TC, are -- defined/reserved for additional 31*3 = 93 job state -- reasons for use with the corresponding attributes: -- jobStateReasons2, jobStateReasons3, and jobStateReasons4. -- This is a type 2 bit definition. See section 7.1.2 on -- page 17. jobStateReasons2(6), -- JmJobStateReasons2TC (pg 45) -- OCTETS: Additional information about the job's current -- state that augments the jmJobState/jobState -- object/attribute. See the description under -- jobStateReasons1 attribute on page 31. -- -- This is a type 2 bit definition. See section 7.1.2 on -- page 17. jobStateReasons3(7), -- JmJobStateReasons3TC (pg 45) -- OCTETS: Additional information about the job's current -- state that augments the jmJobState/jobState -- object/attribute. See the description under -- jobStateReasons1 attribute on page 31. jobStateReasons4(8), -- JmJobStateReasons4TC (pg 45) -- OCTETS: Additional information about the job's current -- state that augments the jmJobState/jobState -- object/attribute. See the description under Bergman, Hastings, Isaacson, Lewis [Page 31] Job Monitoring MIB, V0.81 April 24, 1997 -- jobStateReasons1 attribute on page 31. numberOfInterveningJobs(9), -- Integer32(-2..2147483647) -- INTEGER: The number of jobs that are expected to be -- processed before this job is processed according to the -- implementation's queuing algorithm if no other jobs were -- to be submitted. In other words, this value is the job's -- queue position. The agent shall return a value of 0 for -- this attribute when this job starts processing (since -- there are no jobs in front of the job). deviceAlertCode(10), -- PrtAlertCodeTC (Printer-MIB) -- INTEGER: The device alert code when the job is stopped -- because the device needs attention, i.e., needs human -- intervention. When the device is a printer, this device -- alert code shall be the printer alert code defined by the -- Printer MIB[1] using the PrtAlertCodeTC textual -- convention or equivalent. processingMessage(11), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: A coded character set message that -- is generated during the processing of the job as a simple -- form of processing log to show progress and any problems. -- -- There is no restriction on the same message in multiple -- rows. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Job Identification attributes -- -- The following attributes help an end user, a system -- operator, or an accounting program identify a job. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ serverAssignedJobName(12), -- OCTET STRING(SIZE(0..63)) -- OCTETS: Configuration 3 only: The human readable string -- name of the job as assigned by the server that submitted -- the job to the device that the agent in instrumenting -- with this MIB. -- -- NOTE - This attribute is intended for enabling a user to -- find his/her job that a server submitted to a device -- after the user submitted the job to the server when the -- jmJobIDGroup is not implemented. jobName(13), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The human readable string name of the job as -- assigned by the submitting user to help the user -- distinguish between his/her various jobs. This name does -- not need to be unique. -- -- This attribute is intended for enabling a user or the -- user's application to convey a job name that may be -- printed on a start sheet, returned in a query result, or Bergman, Hastings, Isaacson, Lewis [Page 32] Job Monitoring MIB, V0.81 April 24, 1997 -- used in notification or logging messages. -- -- If this attribute is not specified when the job is -- submitted, no job name is assumed, but implementation -- specific defaults are allowed, such as the value of the -- documentName resource item of the first document in the -- job or the fileName resource item of the first document -- in the job. -- -- The jobName attribute is distinguished from the -- jobComment attribute, in that the jobName attribute is -- intended to permit the submitting user to distinguish -- between different jobs that he/she has submitted. The -- jobComment attribute is intended to be free form -- additional information that a user might wish to use to -- communicate with himself/herself, such as a reminder of -- what to do with the results or to indicate a different -- set of input parameters were tried in several different -- job submissions. jobServiceTypes(14), -- JmJobServiceTypesTC (pg 44) -- INTEGER: Specifies the type(s) of service to which the -- job has been submitted (print, fax, scan, etc.). The -- service type is bit encoded with each job service type so -- that more general and arbitrary services can be created, -- such as services with more than one destination type, or -- ones with only a source or only a destination. For -- example, a job service might scan, faxOut, and print a -- single job. In this case, three bits would be set in the -- jobServiceTypes attribute, corresponding to the -- hexadecimal values: 0x8 + 0x20 + 0x4, respectively, -- yielding: 0x2C. -- -- Whether this attribute is set from a job attribute -- supplied by the job submission client or is set by the -- recipient job submission server or device depends on the -- job submission protocol. This attribute shall be -- implemented if the server or device has other types in -- addition to or instead of printing. -- -- One of the purposes of this attribute is to permit a -- requester to filter out jobs that are not of interest. -- For example, a printer operator may only be interested in -- jobs that include printing. That is why this attribute -- is in the job identification category. jobOwner(15), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The coded character set name of the user that -- submitted the job. The method of assigning this user -- name will be system and/or site specific but the method -- must insure that the name is unique to the network that -- is visible to the client and target device. -- -- This value should be the authenticated name of the user -- submitting the job. Bergman, Hastings, Isaacson, Lewis [Page 33] Job Monitoring MIB, V0.81 April 24, 1997 jobAccountName(16), -- OCTET STRING(SIZE(0..63)) -- OCTETS: Arbitrary binary information which may be coded -- character set data or encrypted data supplied by the -- submitting user for use by accounting services to -- allocate or categorize charges for services provided, -- such as a customer account name. -- -- NOTE: This attribute need not be printable characters. jobSourceChannelIndex(17), -- Integer32(0..2147483647) -- INTEGER: The index of the row in the associated Printer -- MIB[1] of the channel which is the source of the print -- job. -- -- NOTE - the Job Monitoring MIB points to the Channel row -- in the Printer MIB[1], so there is no need for a port -- attribute in the Job Monitoring MIB, since the PWG is -- adding a prtChannelInformation object to the Channel -- table of the draft Printer MIB. jobSourcePlatformType(18), -- JmJobSourcePlatformTypeTC -- (pg 21) -- INTEGER: The source platform type of the immediate -- upstream submitter that submitted the job to the server -- (configuration 2) or device (configuration 1 and 3) that -- the agent is instrumenting. For configuration 1, this is -- the type of the client that submitted the job to the -- device; for configuration 2, this is the type of the -- client that submitted the job to the server; and for -- configuration 3, this is the type of the server that -- submitted the job to the device. submittingServerName(19), -- OCTET STRING(SIZE(0..63)) -- OCTETS: For configuration 3 only: The administrative -- name of the server that submitted the job to the device. submittingApplicationName(20), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The name of the client application (not the -- server in configuration 3) that submitted the job to the -- server or device. deviceNameRequested(21), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The administratively defined coded character set -- name of the target device requested by the submitting -- user. For configuration 1, its value corresponds to the -- Printer MIB[1]: prtGeneralPrinterName object (added to -- the draft Printer MIB) for printers. For configuration 2 -- and 3, its value is the name of the logical or physical -- device that the user supplied to indicate to the server -- on which device(s) they wanted the job to be processed. queueNameRequested(22), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The administratively defined coded character set -- name of the target queue requested by the submitting Bergman, Hastings, Isaacson, Lewis [Page 34] Job Monitoring MIB, V0.81 April 24, 1997 -- user. For configuration 1, its value corresponds to the -- queue in the device that the agent is instrumenting. For -- configuration 2 and 3, its value is the name of the queue -- that the user supplied to indicate to the server on which -- device(s) they wanted the job to be processed. -- -- NOTE - typically an implementation should support either -- the deviceNameRequested or queueNameRequested attribute, -- but not both. physicalDeviceIndex(23), -- hrDeviceIndex (see HR MIB) -- INTEGER: MULTI-ROW: The index of the physical device -- MIB instance requested/used, such as the Printer MIB[1]. -- This value is an hrDeviceIndex value. See the Host -- Resources MIB[6]. physicalDeviceName(24), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The name of the physical device to -- which the job is assigned. numberOfDocuments(25), -- Integer32(0..2147483647) -- INTEGER: The number of documents in this job. If this -- attribute is not present, the number of documents shall -- be 1. fileName(26), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The coded character set file name of -- the document. -- -- There is no restriction on the same file name in multiple -- rows. documentName(27), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The coded character set name of the -- document. -- -- There is no restriction on the same document name in -- multiple rows. jobComment(28), -- OCTET STRING(SIZE(0..63)) -- OCTETS: An arbitrary human-readable coded character text -- string supplied by the submitting user or the job -- submitting application program for any purpose. For -- example, a user might indicate what he/she is going to do -- with the printed output or the job submitting application -- program might indicate how the document was produced. -- -- The jobComment attribute is not intended to be a name; -- see the jobName attribute. documentFormatIndex(29), -- Integer32(0..2147483647) -- INTEGER: MULTI-ROW: The interpreter language family -- index in the Printer MIB[1] of the -- prtInterpreterLangFamily object, that this job -- requires/uses. A document or a job may use more than one Bergman, Hastings, Isaacson, Lewis [Page 35] Job Monitoring MIB, V0.81 April 24, 1997 -- PDL. -- -- NOTE - As with all intensive attribute items where -- multiple rows are allowed, there shall be only one -- distinct row for each distinct PDL; there shall be no -- duplicates. -- -- NOTE - This attribute type is intended to be used with an -- agent that implements the Printer MIB and shall not be -- used if the agent does not implement the Printer MIB. -- Such as agent shall use the documentFormatType attribute -- instead. documentFormatType(30), -- PrtInterpreterLangFamilyTC -- INTEGER: MULTI-ROW: The interpreter language family -- corresponding to the Printer MIB[1] -- prtInterpreterLangFamily object, that this job -- requires/uses. A document or a job may use more than one -- PDL. -- -- NOTE - This attribute is represented by a type 2 enum -- defined in the draft Printer MIB[1], but is not in RFC -- 1759. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Job Parameter attributes -- -- The following attributes represent input parameters -- supplied by the submitting client in the job submission -- protocol. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobPriority(31), -- Integer32(1..100) -- INTEGER: The priority for scheduling the job. It is used -- by servers and devices that employ a priority-based -- scheduling algorithm. -- -- A higher value specifies a higher priority. The value 1 -- is defined to indicate the lowest possible priority (a -- job which a priority-based scheduling algorithm shall -- pass over in favor of higher priority jobs). The value -- 100 is defined to indicate the highest possible priority. -- Priority is expected to be evenly or 'normally' -- distributed across this range. The mapping of vendor- -- defined priority over this range is implementation- -- specific. jobProcessAfterDateAndTime(32), -- DateAndTime (SNMPv2-TC) -- INTEGER: The calendar date and time of day after which -- the job shall become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server shall set the value of the job's -- jmJobState/jobState object/attribute to held and add the -- jobProcessAfterSpecified bit value to the job's Bergman, Hastings, Isaacson, Lewis [Page 36] Job Monitoring MIB, V0.81 April 24, 1997 -- jobStateReasons1 attribute and shall not schedule the job -- for processing until the specified date and time has -- passed. When the specified date and time arrives, the -- server shall remove the jobProcessAfterSpecified bit -- value from the job's jobStateReasons1 attribute and, if -- no other reasons remain, shall change the job's -- jmJobState and the job's jobState attribute to pending so -- that the job becomes a candidate for being scheduled on -- devices(s). -- -- The agent shall assign an empty value to the -- jobProcessAfterDateAndTime attribute when no process -- after time has been specified, so that the job shall be a -- candidate for processing immediately. jobHoldUntil(33), -- OCTET STRING(SIZE(0..63)) -- OCTETS: The named time period during which the job shall -- become a candidate for processing, such as 'no-hold', -- 'evening', 'night', 'weekend', 'second-shift', 'third- -- shift', etc., as defined by the system administrator. -- Until that time period arrives, the job shall be in the -- held state with the jobHoldUntilSpecified value in the -- jobStateReasons1 attribute. outputBinIndex(34), -- Integer32(0..2147483647) -- INTEGER: MULTI-ROW: The output subunit index in the -- Printer MIB[1] of the output bin to which all or part of -- the job is placed in. outputBinName(35), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The name of the output bin to which -- all or part of the job is placed in. sides(36), -- Integer32(-2..1) -- INTEGER: MULTI-ROW: The number of sides that any -- document in this job requires/used. finishing(37), -- JmFinishingTC (pg 21) -- INTEGER: MULTI-ROW: Type of finishing that any document -- in this job requires/used. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Image Quality attributes (requested and consumed) -- -- For devices that can vary the image quality. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ printQualityRequested(38), -- JmPrintQualityTC (pg 23) -- INTEGER: MULTI-ROW: The print quality selection -- requested for document in the job for printers that allow -- quality differentiation. printQualityUsed(39), -- JmPrintQualityTC (pg 23) -- INTEGER: MULTI-ROW: The print quality selection Bergman, Hastings, Isaacson, Lewis [Page 37] Job Monitoring MIB, V0.81 April 24, 1997 -- actually used by documents in the job for printers that -- allow quality differentiation. tonerEcomonyRequested(40), -- JmTonerEconomyTC (pg 23) -- INTEGER: MULTI-ROW: The print quality selection -- requested for documents in the job for printers that -- allow toner quality differentiation. tonerEcomonyUsed(41), -- JmTonerEconomyTC (pg 23) -- INTEGER: MULTI-ROW: The print quality selection -- actually used by documents in the job for printers that -- allow toner quality differentiation. tonerDensityRequested(42), -- Integer32(1..20) -- INTEGER: MULTI-ROW: The toner density requested for -- documents in this job for devices that can vary toner -- density levels. Level 1 is the lowest density and level -- 20 is the highest density level. Devices with a smaller -- range, shall map the 1-20 range evenly onto the -- implemented range. tonerDensityUsed(43), -- Integer32(1..20) -- INTEGER: MULTI-ROW: The toner density used by documents -- in this job for devices that can vary toner density -- levels. Level 1 is the lowest density and level 20 is -- the highest density level. Devices with a smaller range, -- shall map the 1-20 range evenly onto the implemented -- range. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Job Progress attributes (requested and consumed) -- -- Pairs of these attributes can be used by monitoring -- applications to show 'thermometers' of progress to users. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobCopiesRequested(44), -- Integer32(-2..2147483647) -- INTEGER: The number of copies of the entire job that are -- to be produced. jobCopiesCompleted(45), -- Integer32(-2..2147483647) -- INTEGER: The number of copies of the entire job that -- have been completed so far. documentCopiesRequested(46), -- Integer32(-2..2147483647) -- INTEGER: The total count of the number of document -- copies requested. If there are documents A, B, and C, -- and document B is specified to produce 4 copies, the -- number of document copies requested is 6 for the job. documentCopiesCompleted(47), -- Integer32(-2..2147483647) -- INTEGER: The total count of the number of document -- copies completed so far for the job as a whole. If there -- are documents A, B, and C, and document B is specified to Bergman, Hastings, Isaacson, Lewis [Page 38] Job Monitoring MIB, V0.81 April 24, 1997 -- produce 4 copies, the number of document copies starts a -- 0 and runs up to 6 for the job as the job processes. jobKOctetsRequested(48), -- Integer32(-2..2147483647) -- INTEGER: The total number of K (1024) octets being -- requested to be processed in the job, including document -- and job copies. The agent shall round the actual number -- of octets up to the next highest K. Thus 0 octets shall -- be represented as 0, 1-1024 octets shall be represented -- as 1, 1025-2048 shall be represented as 2, etc. -- -- The server/device may update the value of this attribute -- after each document has been transferred to the -- server/device or the server/device may provide this value -- after all documents have been transferred to the -- server/device, depending on implementation. In other -- words, while the job is in the held state with the -- jobStateReasons1 attribute containing a documentsNeeded -- or preProcessing value, the value of the -- jobKOctetsRequested attribute depends on implementation -- and may not correctly reflect the size of the job. -- -- In computing this value, the server/device shall include -- the multiplicative factors contributed by (1) the number -- of document copies, and (2) the number of job copies, -- independent of whether the device can process multiple -- copies of the job or document without making multiple -- passes over the job or document data and independent of -- whether the output is collated or not. Thus the -- server/device computation is independent of the -- implementation and shall be: -- -- (1) Document contribution: Multiply the size of each -- document in octets by the number of document copies -- of that document. -- -- (2) Add each document contribution together. -- -- (3) Job copy contribution: Multiply the job size by -- the number of job copies. -- -- (4) Round up the result to the next higher K (1024 -- multiple). jobKOctetsTransferred(49), -- Integer32(-2..2147483647) -- INTEGER: The number of K (1024) octets transferred to -- the server or device that the agent is instrumenting. -- This count is independent of the number of copies of the -- job or documents that will be produced, but is just a -- measure of the number of bytes transferred to the server -- or device. -- -- The agent shall round the actual number of octets -- completed up to the next higher K. Thus 0 octets is -- represented as 0, 1-1023, is represented as 1, 1024-2047 Bergman, Hastings, Isaacson, Lewis [Page 39] Job Monitoring MIB, V0.81 April 24, 1997 -- is 2, etc. When the job completes, the values of the -- jobKOctetsRequested and the jobKOctetsTransferred -- attributes shall be equal. -- -- NOTE - The jobKOctetsTransferred can be used in the -- numerator with the jobKOctetsRequested attribute in the -- denominator in order to produce a "thermometer" that -- indicates the progress of the job for agents that do not -- instrument the jobKOctetsCompleted attribute. jobKOctetsCompleted(50), -- Integer32(-2..2147483647) -- INTEGER: The number of K (1024) octets currently -- processed by the server or device, including document and -- job copies. For printing, the completed count only -- includes processing (interpreting) if the implementation -- distinguishes between the processing and printing states; -- otherwise, the completed count includes both processing -- (interpreting) and marking combined together. For -- scanning, the completed count only includes scanning, if -- the implementation distinguishes between the processing -- and (to be registered) scanning states; otherwise the -- completed count includes both scanning and processing -- (formatting). -- -- The agent shall round the actual number of octets -- completed up to the next higher K. Thus 0 octets is -- represented as 0, 1-1023, is represented as 1, 1024-2047 -- is 2, etc. When the job completes, the values of the -- jobKOctetsRequested and the jobKOctetsCompleted -- attributes shall be equal. -- -- For multiple copies generated from a single data stream, -- the value shall be incremented as if each copy was -- printed from a new data stream without resetting the -- count between copies. See the pagesCompletedCurrentCopy -- attribute that is reset on each document copy. -- -- NOTE - The jobKOctetsCompleted can be used in the -- numerator with the jobKOctetsRequested attribute in the -- denominator in order to produce a "thermometer" that -- indicates the progress of the job. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Impression attributes -- -- For a print job, an impression is the marking of the -- entire side of a sheet. Two-sided processing involves two -- impressions per sheet. Two-up is the placement of two -- logical pages on one side of a sheet and so is still a -- single impression. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ impressionsSpooled(51), -- Integer32(-2..2147483647) -- INTEGER: The number of impressions spooled to the server Bergman, Hastings, Isaacson, Lewis [Page 40] Job Monitoring MIB, V0.81 April 24, 1997 -- or device for the job so far. impressionsSentToDevice(52), -- Integer32(-2..2147483647) -- INTEGER: The number of impressions sent to the device -- for the job so far. impressionsInterpreted(53), -- Integer32(-2..2147483647) -- INTEGER: The number of impressions interpreted for the -- job so far. impressionsRequested(54), -- Integer32(-2..2147483647) -- INTEGER: The number of impressions requested by this job -- to produce. impressionsCompleted(55), -- Integer32(-2..2147483647) -- INTEGER: The total number of impressions completed by -- the device for this job so far. For printing, the -- impressions completed includes interpreting, marking, and -- stacking the output. For other types of job services, -- the number of impressions completed includes the number -- of impressions processed. impressionsCompletedCurrentCopy(56), -- Integer32(-2.. -- 2147483647) -- INTEGER: The number of impressions completed by the -- device for the current copy of the current document so -- far. For printing, the impressions completed includes -- interpreting, marking, and stacking the output. For -- other types of job services, the number of impressions -- completed includes the number of impressions processed. -- -- This value shall be reset to 0 for each document in the -- job and for each document copy. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Page attributes -- -- A page is a logical page. Number up can impose more than -- one page on a single side of a sheet. Two-up is the -- placement of two logical pages on one side of a sheet so -- that each side counts as two pages. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ pagesRequested(57), -- Integer32(-2..2147483647) -- INTEGER: The number of logical pages requested by the -- job to be processed. pagesCompleted(58), -- Integer32(-2..2147483647) -- INTEGER: The total number of logical pages completed for -- this job so far. pagesCompletedCurrentCopy(59), -- Integer32(-2..2147483647) -- INTEGER: The number of logical pages completed for the -- current copy of the document so far. This value shall be Bergman, Hastings, Isaacson, Lewis [Page 41] Job Monitoring MIB, V0.81 April 24, 1997 -- reset to 0 for each document in the job and for each -- document copy. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Sheet attributes -- -- The sheet is a single piece of a medium, whether printing -- on one or both sides. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sheetsRequested(60), -- Integer32(-2..2147483647) -- INTEGER: The total number of medium sheets requested to -- be processed for this job. sheetsCompleted(61), -- Integer32(-2..2147483647) -- INTEGER: The total number of medium sheets that have -- completed marking and stacking for the entire job so far -- whether those sheets have been processed on one side or -- on both. sheetsCompletedCurrentCopy(62), -- Integer32(-2..2147483647) -- INTEGER: The number of medium sheets that have completed -- marking and stacking for the current copy of a document -- in the job so far whether those sheets have been -- processed on one side or on both. -- -- The value of this attribute shall be reset to 0 as each -- document in the job starts being processed and for each -- document copy as it starts being processed. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Resources attributes (requested and consumed) -- -- Pairs of these attributes can be used by monitoring -- applications to show 'thermometers' of usage to users. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mediumRequestedType(63), -- JmMediumTypeTC (pg 23) -- OCTETS: MULTI-ROW: The type of the medium that is -- required by the job. mediumRequestedName(64), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The name of the medium that is -- required by the job. mediumConsumedName(65), -- OCTET STRING(SIZE(0..63)) -- AND -- Integer32(-2..2147483647) -- OCTETS: MULTI-ROW: The name of the medium AND -- -- INTEGER: the number of sheets that have been consumed so -- far whether those sheets have been processed on one side -- or on both. This attribute shall have both values. Bergman, Hastings, Isaacson, Lewis [Page 42] Job Monitoring MIB, V0.81 April 24, 1997 colorantRequestedIndex(66), -- Integer32(0..2147483647) -- INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) -- in the Printer MIB[1] of the colorant requested. colorantRequestedName(67), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The name of the colorant requested. colorantConsumedIndex(68), -- Integer32(0..2147483647) -- INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) -- in the Printer MIB[1] of the colorant consumed. colorantConsumedName(69), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The name of the colorant consumed. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Time attributes (set by server or device) -- -- This section of attributes are ones that are set by the -- server or device that accepts jobs. Two forms of time are -- provided. Each form is represented in a separate attribute. -- See section 4.2 on page 14 and section 4.3 on page 15 for the -- conformance requirements for agents and monitoring -- applications, respectively. The two forms are: -- -- DateAndTime is an 8 or 11 octet binary encoded year, -- month, day, hour, minute, second, deci-second with -- optional offset from UTC. See SNMPv2-TC. -- -- NOTE: DateAndTime is not printable characters; it is -- binary. -- -- JmTimeStampTC is the time of day measured in the number of -- seconds since the system was booted. See page 20. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobSubmissionToServerDateAndTime(70), -- DateAndTime (SNMPv2-TC) -- OCTETS: Configuration 2 and 3: The date and time that -- the job was submitted to the server. jobSubmissionToDeviceDateAndTime(71), -- DateAndTime (SNMPv2-TC) -- OCTETS: Configuration 1 and 3: The date and time that -- the job was submitted to the device. jobSubmissionToDeviceTimeStamp(72), -- JmTimeStampTC (pg 20) -- INTEGER: The time that the job was submitted. jobStartedBeingHeldTimeStamp(73), -- JmTimeStampTC (pg 20) -- INTEGER: The time that the job started being held, i.e., -- the time that the job entered the held state most -- recently. If the job has never entered the held state, -- then the value shall be 0 or the attribute shall not be -- present in the table. Bergman, Hastings, Isaacson, Lewis [Page 43] Job Monitoring MIB, V0.81 April 24, 1997 jobStartedProcessingDateAndTime(74), -- DateAndTime (SNMPv2-TC) -- OCTETS: The date and time that the job started -- processing. jobStartedProcessingTimeStamp(75), -- JmTimeStampTC (pg 20) -- INTEGER: The time that the job started processing. jobCompletedDateAndTime(76), -- DateAndTime (SNMPv2-TC) -- OCTETS: The date and time that the job completed -- processing and the medium is completely stacked in the -- output bin, i.e., when the job entered the completed -- state. jobCompletedTimeStamp(77), -- JmTimeStampTC (pg 20) -- INTEGER: The time that the job completed processing and -- the medium is completely stacked in the output bin, i.e., -- when the job entered the completed state. jobProcessingCPUTime(78) -- Integer32(-2..2147483647) -- INTEGER: The amount of CPU time that the job has been -- processing in seconds. If the job needs attention, that -- elapsed time shall not be included. In other words, the -- jobProcessingCPUTime value should be relatively -- repeatable when the same job is submitted again. } JmJobServiceTypesTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the type(s) of service to which the job has been submitted (print, fax, scan, etc.). The service type is represented as an enum that is bit encoded with each job service type so that more general and arbitrary services can be created, such as services with more than one destination type, or ones with only a source or only a destination. For example, a job service might scan, faxOut, and print a single job. In this case, three bits would be set in the jobServiceTypes attribute, corresponding to the hexadecimal values: 0x8 + 0x20 + 0x4, respectively, yielding: 0x2C. Whether this attribute is set from a job attribute supplied by the job submission client or is set by the recipient job submission server or device depends on the job submission protocol. With either implementation, the agent shall return a non-zero value for this attribute indicating the type of the job. One of the purposes of this attribute is to permit a requester to filter out jobs that are not of interest. For example, a printer operator may only be interested in jobs that include Bergman, Hastings, Isaacson, Lewis [Page 44] Job Monitoring MIB, V0.81 April 24, 1997 printing. That is why the attribute is in the job identification category. The following service component types are defined (in hexadecimal) and are assigned a separate bit value for use with the jobServiceTypes attribute: other 0x1 The job contains some document production instructions that are not one of the identified types. unknown 0x2 The job contains some document production instructions whose type is unknown to the agent. print 0x4 The job contains some document production instructions that specify printing scan 0x8 The job contains some document production instructions that specify scanning faxIn 0x10 The job contains some document production instructions that specify receive fax faxOut 0x20 The job contains some document production instructions that specify sending fax getFile 0x40 The job contains some document production instructions that specify accessing files or documents putFile 0x80 The job contains some document production instructions that specify storing files or documents mailList 0x100 The job contains some document production instructions that specify distribution of documents using an electronic mail system. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 7.1.2 on page 17." SYNTAX INTEGER(0..2147483647) -- 31 bits, all but sign bit Bergman, Hastings, Isaacson, Lewis [Page 45] Job Monitoring MIB, V0.81 April 24, 1997 JmJobStateReasons1TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used with the jobStateReasons1 attribute to provides additional information regarding the jmJobState/jobState object/attribute. The jobStateReasons1 attributes identifies the reason or reasons that the job is in the held, pending, processing, printing, needsAttention, canceled, or completed state. The server shall indicate the particular reason(s) by setting the value of the jobStateReasons1 attribute. While the job states cannot be added to without impacting deployed clients, it is the intent that additional JmJobStateReasons1TC enums can be defined without impacting deployed clients. In other words, the JmJobStateReasons1TC is intended to be extensible. When the job does not have any reasons for being in its current state, the server shall set the value of the jobStateReasons1 attribute to zeros. Companion job state reasons TCs: JmJobStateReasons2TC, JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for additional 31*3 = 93 job state reasons. This is a type 2 bit definition. See section 7.1.2 on page 17. The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: other 0x1 The job state reason is not one of the standardized or registered reasons. unknown 0x2 The job state reason is not known to the agent. documentsNeeded 0x4 The job is in the held state because the server or device is waiting for the job's files to start and/or finish being transferred before the job can be scheduled to be processed. jobHoldSet 0x8 The job is in the held state because the client specified that the job is to be held. jobProcessAfterSpecified 0x10 The job is in the held state because the client specified a time specification reflected in the value of the job's jobProcessAfterDateAndTime attribute that has not yet occurred. requiredResourcesNotReady 0x20 Bergman, Hastings, Isaacson, Lewis [Page 46] Job Monitoring MIB, V0.81 April 24, 1997 The job is in the held state because at least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. successfulCompletion 0x40 The job is in the completed state having completed successfully. completedWithWarnings 0x80 The job is in the canceled or completed states having completed with warnings. completedWithErrors 0x100 The job is in the canceled or completed states having completed with errors (and possibly warnings too). canceledByUser 0x200 The job is in the canceled, state having been canceled by the user. canceledByOperator 0x400 The job is in the canceled state having been canceled by the operator. abortedBySystem 0x800 The job is in the canceled, state having been aborted by the system. logfilePending 0x1000 The job's logfile is pending file transfer. logfileTransferring 0x2000 The job is in the canceled or completed states and the job's logfile is being transferred. The following additional job state reasons have been added to specify sub-states of the held or completed states that may be used to represent states that are in ISO DPA[2]: jobPreProcessing 0x4000 The job has been created on the server or device but the submitting client is in the process of adding additional job components and no documents have started processing. The job maybe in the process of being checked by the server/device for attributes, defaults being applied, a device being selected, etc. jobPaused 0x8000 The job has been indefinitely suspended by a client issuing an operation to suspend the job so that other jobs may proceed using the same devices. The client may issue an operation to resume the paused job at any time, in which case the server or device places the job in the held or Bergman, Hastings, Isaacson, Lewis [Page 47] Job Monitoring MIB, V0.81 April 24, 1997 pending states and the job is eventually resumed at the point where the job was paused. jobInterrupted 0x10000 The job has been interrupted while processing by a client issuing an operation that specifies another job to be run instead of the current job. The server or device will automatically resume the interrupted job when the interrupting job completes. jobRetained 0x20000 The job is being retained by the server or device after processing and all of the media have been successfully stacked in the output bin(s). The job (1) has completed successfully or with warnings or errors, (2) has been aborted while printing by the server/device, or (3) has been canceled by the submitting user or operator before or during processing. The job's jobStateReasons1 attribute shall contain the reasons that the job has entered the completed state. While the jobRetained state reason is , all of the job's document data (and submitted resources, such as fonts, logos, and forms, if any) are retained by the server or device; thus a client could issue an operation to resubmit the job (or a copy of the job). The following job state reasons have been added to align with the Internet Printing Protocol (IPP): jobHoldUntil 0x40000 The jobHoldUntil(33) attribute was specified for a named time period that is still in the future. The job remains in the held state until the time period arrives and there are no other reasons to hold the job. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 7.1.2 on page 17." SYNTAX INTEGER(0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons2TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used with the jobStateReasons2 attribute to provides additional information regarding the jmJobState/jobState object/attribute. See the description under JmJobStateReasons1TC on page 45. Bergman, Hastings, Isaacson, Lewis [Page 48] Job Monitoring MIB, V0.81 April 24, 1997 The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: cascaded 0x1 After the outbound gateway retrieves all job and document attributes and data, it stores the information into a spool directory. Once it has done this, it sends the supervisor a job-processing event with this job-state-reason which tells the supervisor to transition to a new job state. deletedByAdministrator 0x2 The administrator has issued a Delete operation on the job or a Clean operation on the server or queue containing the job; therefore the job may have been canceled before or during processing, and will have no retention-period or completion-period. discardTimeArrived 0x4 The job has been deleted (canceled with the job-retention- period set to 0) due to the fact that the time specified by the job's job-discard-time has arrived [if the job had already completed, the only action that would have occurred is that the job-retention-period would be set to 0 and the job is deleted]. postProcessingFailed 0x8 The post-processing agent failed while trying to log accounting attributes for the job; therefore the job has been placed into completed state with the retained jobStateReasons1 attribute value for a system-defined period of time, so the administrator can examine it, resubmit it, etc. The post-processing agent is a plug-and-play mechanism which the system and the customer uses to add functionality that is executed after a job has finished processing. submissionInterrupted 0x10 Indicates that the job was not completely submitted for the following reasons: (1) the server has crashed before the job was closed by the client. The server shall put the job into the completed state (and shall not print the job). (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server. The server shall put the job into the completed state (and shall not print the job). (3) the client crashed or failed to close the job before the time-out period. The server shall close the job and put the job into the held state with job-state-reasons of submission-interrupted and job-hold-set and with the job's job-hold attribute set to TRUE. The user may release the job for scheduling by issuing a job submission or management protocol operation. maxJobFaultCountExceeded 0x20 The job has been faulted and returned by the server several Bergman, Hastings, Isaacson, Lewis [Page 49] Job Monitoring MIB, V0.81 April 24, 1997 times and that the job-fault-count exceeded the device's (or server's, if not defined for the device) cfg-max-job-fault- count. The job is automatically put into the held state regardless of the hold-jobs-interrupted-by-device-failure attribute. This job-state-reasons value is used in conjunction with the job-interrupted-by-device-failure value. devicesNeedAttentionTimeOut 0x40 One or more document transforms that the job is using needs human intervention in order for the job to make progress, but the human intervention did not occur within the site- settable time-out value and the server/device has transitioned the job to the held state. needsKeyOperatorTimeOut 0x80 One or more devices or document transforms that the job is using need a specially trained operator (who may need a key to unlock the device and gain access) in order for the job to make progress, but the key operator intervention did not occur within the site-settable time-out value and the server/device has transitioned the job to the held state. jobStartWaitTimeOut 0x100 The server/device has stopped the job at the beginning of processing to await human action, such as installing a special cartridge or special non-standard media, but the job was not resumed within the site-settable time-out value and the server/device has transitioned the job to the held state. Normally, the job is resumed by means outside the job submission protocol, such as some local function on the device. jobEndWaitTimeOut 0x200 The server/device has stopped the job at the end of processing/printing to await human action, such as removing a special cartridge or restoring standard media, but the job was not resumed within the site-settable time-out value and the server/device has transitioned the job to the completed state. Normally, the job is resumed by means outside the job submission protocol, such as some local function on the device, whereupon the job shall transition immediately to the canceled state. jobPasswordWaitTimeOut 0x400 The server/device has stopped the job at the beginning of processing to await input of the job's password, but the human intervention did not occur within the site-settable time-out value and the server/device has transitioned the job to the held state. Normally, the password is input and the job is resumed by means outside the job submission protocol, such as some local function on the device. deviceTimedOut 0x800 A device that the job was using has not responded in a Bergman, Hastings, Isaacson, Lewis [Page 50] Job Monitoring MIB, V0.81 April 24, 1997 period specified by the device's site-settable attribute. connectingToDeviceTimeOut 0x1000 The server is attempting to connect to one or more devices which may be dial-up, polled, or queued, and so may be busy with traffic from other systems, but server was unable to connect to the device within the site-settable time-out value and the server has transitioned the job to the held state. transferring 0x2000 The job is being transferred to a down stream server or device. queuedInDevice 0x4000 The job has been queued in a down stream server or device. jobCleanup 0x8000 The server/device is performing cleanup activity as part of ending normal processing. processingToStopPoint 0x10000 The requester has issued an operation to interrupt the job and the server/device is processing up until the specified stop point occurs. jobPasswordWait 0x20000 The server/device has selected the job to be next to process, but instead of assigning resources and started the job processing, the server/device has transitioned the job to the held state to await entry of a password (and dispatched another job, if there is one). The user resumes the job either locally or by issuing a remote operation and supplying a job-password=secret-code input parameter that must match the job's job-password attribute. validating 0x40000 The server/device is validating the job after accepting the job. The job state may be held, pending, or processing. queueHeld 0x80000 The operator has held the entire queue by means outside the scope of the Job model. jobProofWait 0x100000 The job has produced a single proof copy and is in the held state waiting for the requester to issue an operation to release the job to print normally, obeying the job-copies and copy-count job and document attributes that were originally submitted. heldForDiagnostics 0x200000 The system is running intrusive diagnostics, so the all jobs are being held. Bergman, Hastings, Isaacson, Lewis [Page 51] Job Monitoring MIB, V0.81 April 24, 1997 serviceOffLine 0x400000 The service/document transform is off-line and accepting no jobs. All pending jobs are put into the held state. This could be true if its input is impaired or broken. noSpaceOnServer 0x800000 The job is held because there is no room on the server to store all of the job. For example, there is no room for the document data or a scan-to-file job. pinRequired 0x1000000 The System Administrator settable device policy is (1) to require PINs, and (2) to hold jobs that do not have a pin supplied as an input parameter when the job was created. The requester shall either (1) enter a pin locally at the device or issue a remote operation supplying the PIN in order for the job to be able to proceed. exceededAccountLimit 0x2000000 The account for which this job is drawn has exceeded its limit. This condition should be detected before the job is scheduled so that the user does not wait until his/her job is scheduled only to find that the account is overdrawn. This condition may also occur while the job is processing either as processing begins or part way through processing. An overdraft mechanism should be included to be user- friendly, so as to minimize the chances that the job cannot finish or that media is wasted. For example, the server/device should finish the current copy for a job with collated document copies, rather than stopping in the middle of the current document copy. heldForRetry 0x4000000 The job encountered some errors that the server/device could not recover from with its normal retry procedures, but the error is worth trying the job later, such as phone number busy or remote file system in-accessible. For such a situation, the server/device shall add the held-for-retry value to the job's jobStateReasons2 attribute and transition the job from the processing to the held, rather than to the completed state. The following values are from the X/Open PSIS draft standard: canceledByShutdown 0x8000000 The job was canceled because the server or device was shutdown before completing the job. The job shall be placed in the pending state [if the job was not started, else the job shall be placed in the terminating state]. deviceUnavailable 0x10000000 This job was aborted by the system because the device is currently unable to accept jobs. This reason [shall be] used Bergman, Hastings, Isaacson, Lewis [Page 52] Job Monitoring MIB, V0.81 April 24, 1997 in conjunction with the reason aborted-by-system. The job shall be placed in the pending state. wrongDevice 0x20000000 This job was aborted by the system because the device is unable to handle this particular job; the spooler should try another device. This reason [shall be] used in conjunction with the reason aborted-by- system. The job shall be pending if the queue contains other physical devices that the job could print on, and the spooler is capable of not sending the job back to a physical device that has rejected the job for this job-state-reasons value. Otherwise, [the job] shall be placed in the completed state with the retained value set in the jobStateReasons2 attribute. badJob 0x40000000 This job was aborted by the system because this job has a major problem, such as an ill-formed PDL; the spooler should not even try another device. This reason shall be used in conjunction with the reason aborted-by-system. The job shall be placed in the terminating state. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 7.1.2 on page 17." SYNTAX INTEGER(0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons3TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used with the jobStateReasons3 attribute to provides additional information regarding the jmJobState/jobState object/attribute. See the description under JmJobStateReasons1TC on page 45. The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: jobInterruptedByDeviceFailure 0x1 A device or the print system software that the job was using has failed while the job was processing. The device is keeping the job in the held state until an operator can determine what to do with the job. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 7.1.2 on page 17." Bergman, Hastings, Isaacson, Lewis [Page 53] Job Monitoring MIB, V0.81 April 24, 1997 SYNTAX INTEGER(0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons4TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used in the jobStateReasons4 attribute to provides additional information regarding the jmJobState/jobState object/attribute. See the description under JmJobStateReasons1TC on page 45. The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: none yet defined. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 7.1.2 on page 17." SYNTAX INTEGER(0..2147483647) -- 31 bits, all but sign bit -- The following tables 1-4 show the JmJobStateReasonsnTC values -- (n=1..4) and the job states for which they are applicable: -- Table 1 - JmJobStateReasons1TC: Legal Job States for each Job State -- Reason -- Descriptive Name Allowed job states -- documents-needed(1) held -- job-hold-set(2) held -- job-process-after-specified(3) held -- required-resources-not-ready(4) held -- successful-completion(5) completed -- completed-with-warnings(6) completed -- completed-with-errors(7) completed Bergman, Hastings, Isaacson, Lewis [Page 54] Job Monitoring MIB, V0.81 April 24, 1997 -- Descriptive Name Allowed job states -- canceled-by-user(8) canceled -- canceled-by-operator(9) canceled -- aborted-by-system(10) canceled -- logfile-pending(11) canceled -- logfile-transferring(12) canceled -- jobPreProcessing(45) held -- jobPaused(46) held -- jobInterrupted(47) held -- jobRetained(48) canceled, completed -- jobHoldUntilSpecified(49) held -- Table 2 - JmJobStateReasons2TC: Legal Job States for each Job State -- Reason -- Descriptive Name Allowed job states -- cascaded(13) canceled -- deleted-by-administrator(14) canceled -- discard-time-arrived(15) canceled -- postprint-failed(16) canceled, completed -- submission-interrupted(17) canceled -- max-job-fault-count-exceeded(18) canceled -- devices-need-attention-time-out(19) held, canceled Bergman, Hastings, Isaacson, Lewis [Page 55] Job Monitoring MIB, V0.81 April 24, 1997 -- Descriptive Name Allowed job states -- needs-key-operator-time-out(20) held, canceled -- job-start-wait-time-out(21) canceled -- job-end-wait-time-out(22) canceled -- job-password-wait-time-out(23) held, pending -- device-timed-out(24) held, canceled -- connecting-to-device-time-out(25) held, canceled -- transferring(26) processing -- queued-in-device(27) processing -- job-cleanup(28) processing -- processing-to-stop-point(29) processing -- job-password-wait(30) held, processing -- validating(31) held, pending, processing -- queue-held(32) held -- job-proof-wait(33) held -- held-for-diagnostics(34) held -- service-off-line(35) held -- no-space-on-server(36) held -- pin-required(37) held, canceled -- exceeded-account-limit(38) held, canceled -- held-for-retry(39) held -- canceledByShutdown(40) canceled -- deviceUnavailable(41) pending -- wrongDevice(42) canceled Bergman, Hastings, Isaacson, Lewis [Page 56] Job Monitoring MIB, V0.81 April 24, 1997 -- Descriptive Name Allowed job states -- badJob(43) canceled -- Table 3 - JmJobStateReasons3TC: Legal Job States for each Job State -- Reason -- jobInterruptedByDeviceFailure(44) held Bergman, Hastings, Isaacson, Lewis [Page 57] Job Monitoring MIB, V0.81 April 24, 1997 -- The General Group (Mandatory) -- The jmGeneralGroup consists entirely of the jmGeneralTable. -- Implementation of every object in this group is mandatory. -- See Section 4 entitled 'Conformance Considerations' on page 14. jmGeneral OBJECT IDENTIFIER ::= { jobmonMIB 5 } jmGeneralTable OBJECT-TYPE SYNTAX SEQUENCE OF JmGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmGeneralTable consists of information of a general nature that are per-job-set, but are not per-job. See Terminology and Job Model on page 8 for the definition of a job set." ::= { jmGeneral 1 } jmGeneralEntry OBJECT-TYPE SYNTAX JmGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a job set (queue). An entry shall exist in this table for each job set." INDEX { jmJobSetIndex } ::= { jmGeneralTable 1 } JmGeneralEntry ::= SEQUENCE { jmGeneralNumberOfActiveJobs Integer32(0..2147483647), jmGeneralOldestActiveJobIndex Integer32(0..2147483647), jmGeneralNewestActiveJobIndex Integer32(0..2147483647), jmGeneralJobPersistence Integer32(0..2147483647), jmGeneralAttributePersistence Integer32(0..2147483647), jmGeneralJobSetName OCTET STRING(SIZE(0..63)) } jmGeneralNumberOfActiveJobs OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of active jobs in the jmJobIDTable, jmJobStateTable, and jmAttributeTable, i.e., the total number of jobs that are in neither the completed nor the canceled states. See JmJobStateTC on page 24 for the exact specification of the semantics of the job states. If there are no active jobs, the value of this object shall be 0." ::= { jmGeneralEntry 1 } Bergman, Hastings, Isaacson, Lewis [Page 58] Job Monitoring MIB, V0.81 April 24, 1997 jmGeneralOldestActiveJobIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The jmJobIndex of the oldest active job, i.e., the job in the jmJobStateTable and jmAttributeTable that has been there the longest and has neither completed nor been canceled. When a job completes or is canceled with a jmJobIndex value that matches this object, the agent shall advance the value to the next oldest active job, if any. If there are no active jobs, the agent shall the value of this object to 0." ::= { jmGeneralEntry 2 } jmGeneralNewestActiveJobIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The jmJobIndex of the newest active job, i.e., the job in the jmJobStateTable and jmAttributeTable that has been added most recently and has neither completed nor been canceled. When a new job is accepted by the server or device that the agent is instrumenting, the agent shall increment this object by 1 and store the job attributes in the row specified by the incremented value. If the value would exceed the implementation-defined maximum value for jmJobIndex, the agent shall set the value back to 1, i.e., wrap around to the beginning of the job tables. It is recommended that the largest value for jmJobIndex be much larger than the maximum number of jobs that the implementation can contain at a single time, so as to minimize the pre-mature re-use of jmJobIndex value for a newer job while clients retain the same 'stale' value for an older job. When all jobs become inactive, i.e., enter the completed or canceled state, the agent shall leave the value of this object unchanged. When the server or device is power-cycled, the value of this object shall be persistent, so that new jobs are not assigned the same jmJobIndex as recent jobs before the power cycle. Therefore, the agent shall return the value 0 only on the first power-up of the server or device. NOTE - Applications that wish to efficiently access all of the active jobs may use jmGeneralOldestActiveJobIndex value to start with the oldest active job and continue until they reach the index value equal to jmGeneralNewestActiveJobIndex, skipping over any completed or canceled jobs that might intervene. If an Bergman, Hastings, Isaacson, Lewis [Page 59] Job Monitoring MIB, V0.81 April 24, 1997 application detects that the jmGeneralNewestActiveJobIndex is smaller than jmGeneralOldestActiveJobIndex, the job index has wrapped. In this case, when the application exceeds the maximum job index (detected by a no such object status returned from a GetNext operation for the next conceptual row), the application shall start over at 1 and continue the GetNext operations to find the rest of the active jobs." ::= { jmGeneralEntry 3 } jmGeneralJobPersistence OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time in seconds that an entry will remain in the jmJobIDTable and jmJobStateTable after processing/printing has completed for this instance of the Job Set, i.e., the time in seconds starting when the job enters the completed or canceled state. Depending on implementation, the value of this object may be either: (1) set by the system administrator by means outside this specification or (2)fixed by the implementation." ::= { jmGeneralEntry 4 } jmGeneralAttributePersistence OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time in seconds that an entry will remain in the jmAttributeTable after processing/printing has completed for this instance of the Job Set, i.e., the time in seconds starting when the job enters the completed or canceled state. The value of this object may be either (1) set by the system administrator by means outside this specification or may be (2) fixed by the implementation, depending on implementation. This value shall be equal to or less than the value of jmGeneralJobPersistence. Attributes that are shared between the jmJobIDTable/jmJobStateTable and the jmAttributeTable shall be governed by the larger value in all tables." ::= { jmGeneralEntry 5 } jmGeneralJobSetName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable administratively assigned name of this job set (by means outside of this MIB). Typically, this name will be the name of the job queue. If a server or device has only a single job set, this object can be the administratively assigned name of the server or device itself. This name does not need to be unique, though each job set in a single Job Monitoring MIB should have distinct names. Bergman, Hastings, Isaacson, Lewis [Page 60] Job Monitoring MIB, V0.81 April 24, 1997 NOTE - The purpose of this object is to help the user of the job monitoring application distinguish between several job sets in implementations that support more than one job set." ::= { jmGeneralEntry 6 } -- The Job ID Group (Mandatory) -- The jmJobIDGroup consists entirely of the jmJobIDTable. -- -- The two key indexes that are used in other tables to index jobs: -- jmJobSetIndex and jmJobIndex are materialized in this group. -- -- Implementation of every object in this group is mandatory. -- See Section 4 entitled 'Conformance Considerations' on page 14. jmJobID OBJECT IDENTIFIER ::= { jobmonMIB 6 } jmJobIDTable OBJECT-TYPE SYNTAX SEQUENCE OF JmJobIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmJobIDTable provides a correspondence map (1) between the job submission ID that a client uses to refer to a job and (2) the jmJobSetIndex and jmJobIndex that the Job Monitoring MIB agent assigned to the job and that are used to access the job in all of the other tables in the MIB. If a monitoring application already knows the jmJobIndex of the job it is querying, that application need not use the jmJobIDTable." ::= { jmJobID 1 } jmJobIDEntry OBJECT-TYPE SYNTAX JmJobIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The map from (1) the jmJobSubmissionIDIndex to (2) the jmJobSetIndex and jmJobIndex. An entry shall exist in this table for each job, no matter what the state of the job and no matter what job set the job is in. Each job shall appear in one and only one job set." INDEX { jmJobSubmissionIDIndex } ::= { jmJobIDTable 1 } JmJobIDEntry ::= SEQUENCE { jmJobSubmissionIDIndex OCTET STRING(SIZE(0..32)), jmJobSetIndex Integer32(1..32767), jmJobIndex Integer32(1..2147483647) } Bergman, Hastings, Isaacson, Lewis [Page 61] Job Monitoring MIB, V0.81 April 24, 1997 jmJobSubmissionIDIndex OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A quasi-unique 32-octet string ID which identifies the job uniquely within a particular client-server environment. Either the client or the server assigns the job submission ID for each job. The monitoring application whether in the client or running separately, uses the job submission ID to help the user identify which jmJobIndex was assigned by the agent. There are multiple formats for the jmJobSubmissionIDIndex. Each format shall be registered using the procedures of a type 2 enum. See section entitled: 'IANA Registration of enums' on page 17. The value of jmJobSubmissionIDIndex should be one of the registered format types. The first two octets of the string shall indicate which registered format is being used. The agent shall assign a string of registered format (00) for any job without a Job Submission ID. The format values registered so far are: Format Number Description ------ ------------ 00 Set by the agent when neither the client nor the server assigned a job submission ID. 01 octets 3-10: 8-decimal-digit random number octets 11-32: last 22 bytes of the jobName attribute 02 octets 3-10: 8-decimal-digit sequential number octets 11-32: Client MAC address 03 octets 3-10: 8-decimal-digit sequential number octets 11-32: last 22 bytes of the client URL .. to be registered according to procedures of a type 2 enum. See section 7.3 on page 18. NOTE - the job submission id is only intended to be unique between a limited set of clients for a limited duration of time, namely, for the life time of the job in the context of the server or device that is processing the job. Some of the formats include something that is unique per client and a random number so that the same job submitted by the same client will have a different job submission id. For other formats, where part of the id is guaranteed to be unique for each client, such as the MAC address or URL, a sequential number should suffice for each client (and may be easier for each client to manage). Therefore, the length of the job submission id has been selected to reduce the probability of collision to a very low number, but is not intended to be an absolute guarantee of uniqueness. Bergman, Hastings, Isaacson, Lewis [Page 62] Job Monitoring MIB, V0.81 April 24, 1997 None-the-less, collisions could occur, but without bad consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them." ::= { jmJobIDEntry 1 } jmJobSetIndex OBJECT-TYPE SYNTAX Integer32(1..32767) MAX-ACCESS read-only STATUS current DESCRIPTION "The job set index of the job set in which the job was placed when that server or device accepted the job. This 16-bit value in combination with the jmJobIndex value permits the management application to access the other tables to obtain the job- specific objects. This value shall be the same for a job in the jmJobIDTable as the corresponding jmJobSetIndex value in the jmJobStateTable and jmAttributeTable for this job. The value(s) of the jmJobSetIndex shall be persistent across power cycles, so that clients that have retained jmJobSetIndex values will access the same job sets upon subsequent power-up. NOTE - an implementation that has only one job set, such as a printer with a single queue, shall hard code this object with the value 1. See Terminology and Job Model on page 8 for the definition of a job set." ::= { jmJobIDEntry 2 } jmJobIndex OBJECT-TYPE SYNTAX Integer32(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The sequential, monatonically increasing identifier index for the job generated by the server or device when that server or device accepted the job. This index value permits the management application to access the other tables to obtain the job-specific row entries. This value shall be the index used in the jmJobStateTable and jmAttributeTable for this job. See jmGeneralNewestActiveJobIndex on page 57 for a discussion about the largest value of jmJobIndex for an implementation. NOTE - Agents instrumenting systems that contain jobs with a job identifier of 0 shall map the job identifier value 0 to a jmJobIndex value that is one higher than the highest job identifier value that any job can have on that system." ::= { jmJobIDEntry 3 } -- The Job State Group (Mandatory) -- The jmJobStateGroup consists entirely of the jmJobStateTable. Bergman, Hastings, Isaacson, Lewis [Page 63] Job Monitoring MIB, V0.81 April 24, 1997 -- -- Implementation of every object in this group is mandatory. -- See Section 4 entitled 'Conformance Considerations' on page 14. jmJobStateG OBJECT IDENTIFIER ::= { jobmonMIB 7 } jmJobStateTable OBJECT-TYPE SYNTAX SEQUENCE OF JmJobStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmJobStateTable consists of basic job state and status information for each job in a job set that (1) monitoring applications need to be able to access in a single SNMP Get operation, (2) that have a single value per job, and (3) that shall always be implemented. NOTE - Every accessible object in this table shall have the same value as one of the attributes in the jmAttributeTable. Implementations may either keep a separate copy or may share each value that is common between the jmJobStateTable and the jmAttributeTable. The persistence of the two tables may be different depending on implementation and/or system administrator policy as specified by the jmGeneralJobPersistence and jmGeneralAttributePersistence objects defined on page 58. Thus an accounting application need only copy the entire jmAttributeTable or selected job rows and will obtain all of the information about those jobs and their states." ::= { jmJobStateG 1 } jmJobStateEntry OBJECT-TYPE SYNTAX JmJobStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Basic per-job state and status information. An entry shall exist in this table for each job, no matter what the state of the job is. Each job shall appear in one and only one job set." INDEX { jmJobSetIndex, jmJobIndex } ::= { jmJobStateTable 1 } JmJobStateEntry ::= SEQUENCE { jmJobState JmJobStateTC, -- pg 24 jmJobStateKOctetsCompleted Integer32(-2..2147483647), jmJobStateImpressionsCompleted Integer32(-2..2147483647), jmJobStateAssociatedValue Integer32(-2..2147483647) } jmJobState OBJECT-TYPE SYNTAX JmJobStateTC -- See page 24 MAX-ACCESS read-only Bergman, Hastings, Isaacson, Lewis [Page 64] Job Monitoring MIB, V0.81 April 24, 1997 STATUS current DESCRIPTION "The current state of the job (pending, processing, held, etc.). The value of this object shall always be the same as that of the jobState attribute, so that this information appears in both the jmJobStateTable and the jmAttributeTable simultaneously. See the JmJobStateTC textual-convention on page 20 and the jobState attribute on page 30 in the jmAttributeTable for the full specification of this object/attribute." ::= { jmJobStateEntry 1 } jmJobStateKOctetsCompleted OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of octets completed processing by the server or device measured in units of K (1024) octets. The value of this object shall always be the same as that of the jobKOctetsCompleted attribute, so that this information appears in both the jmJobStateTable and the jmAttributeTable simultaneously. See the jobKOctetsCompleted attribute on page 40 in the jmAttributeTable for the full specification of this object/attribute." ::= { jmJobStateEntry 2 } jmJobStateImpressionsCompleted OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of impressions completed being marked and stacked by the device for this job so far. The value of this object shall always be the same as that of the impressionsCompleted attribute, so that this information appears in both the jmJobStateTable and the jmAttributeTable simultaneously. See the impressionsCompleted attribute on page 41 in the jmAttributeTable for the full specification of this object/attribute." ::= { jmJobStateEntry 3 } jmJobStateAssociatedValue OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the most relevant attribute associated with the job's current state. The value of this object shall always be the same as that of the jobStateAssociatedValue attribute, so that this information Bergman, Hastings, Isaacson, Lewis [Page 65] Job Monitoring MIB, V0.81 April 24, 1997 appears in both the jmJobStateTable and the jmAttributeTable simultaneously. See the jobStateAssociatedValue attribute on page 30 in the jmAttributeTable for the full specification of this object/attribute." ::= { jmJobStateEntry 4 } -- The Attribute Group (Mandatory) -- The jmAttributeGroup consists entirely of the jmAttributeTable. -- -- Implementation of every object in this group is mandatory. -- See Section 4 entitled 'Conformance Considerations' on page 14. -- -- Some attributes are mandatory for agent conformance, and the rest are -- conditionally mandatory. See the specification of the -- JmAttributeTypeTC on page 27 for which attributes are mandatory for -- agents to implement. jmAttribute OBJECT IDENTIFIER ::= { jobmonMIB 8 } jmAttributeTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmAttributeTable shall contain attributes of the job and document(s) for each job in a job set. Instead of allocating distinct objects for each attribute, each attribute is represented as a separate row in the jmAttributeTable. Some attributes represent information about the job and document(s), such as file-names, document-names, submission-time, completion- time, size, etc. Other attributes represent requested and/or consumed resources for each job for use by monitoring and accounting applications. The jmAttributeTable is a per-job table with an extra index for each type of attribute (jmAttributeTypeIndex) that a job can have and an additional index (jmAttributeInstanceIndex) for those attributes that can have multiple instances per job. The jmAttributeTypeIndex object shall contain an enum type that indicates the type of attribute (see JmAttributeTypeTC on page 27). The value of the attribute shall be represented in either the jmAttributeValueAsInteger or jmAttributeValueAsOctets objects, or both, as specified in the JmAttributeTypeTC textual- convention. 1)The agent shall create rows in the jmAttributeTable as the server or device is able to discover the attributes either from the job submission protocol itself or from the document PDL. As the documents are interpreted, the interpreter may discover additional attributes and so the agent adds additional rows to this table. As the attributes that Bergman, Hastings, Isaacson, Lewis [Page 66] Job Monitoring MIB, V0.81 April 24, 1997 represent resources are actually consumed, the usage counter contained in the jmAttributeValueAsInteger object is incremented according to the units indicated in the description of the JmAttributeTypeTC enum." ::= { jmAttribute 1 } jmAttributeEntry OBJECT-TYPE SYNTAX JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes representing information about the job and document(s) or resources required and/or consumed. Zero or more entries shall exist in this table for each job in a job set. Each job shall appear in one and only one job set." INDEX { jmJobSetIndex, jmJobIndex, jmAttributeTypeIndex, jmAttributeInstanceIndex } ::= { jmAttributeTable 1 } JmAttributeEntry ::= SEQUENCE { jmAttributeTypeIndex JmAttributeTypeTC, -- pg 27 jmAttributeInstanceIndex Integer32(1..32767), jmAttributeValueAsInteger Integer32(-2..2147483647), jmAttributeValueAsOctets OCTET STRING(SIZE(0..63)) } jmAttributeTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC -- See page 27 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. The type may identify information about the job or document(s) or may identify a resource required to process the job before the job start processing and/or consumed by the job as the job is processed. Examples of job and document information include: jobCopiesRequested, documentCopiesRequested, jobCopiesCompleted, documentCopiesCompleted, fileName, and documentName. Examples of resources required and consumed include: jobKOctetsRequested, jobKOctetsCompleted, pagesRequested, pagesCompleted, mediumRequested, and mediumConsumed, respectively. In the definitions of the enums in the JmAttributeTypeTC textual convention, each description indicates whether the value of the attribute shall be represented using the jmAttributeValueAsInteger or the jmAttributeValueAsOctets objects by the initial tag: 'INTEGER:' or 'OCTETS:', respectively. A very few attributes use both objects (mediumConsumed) and so have both tags. Bergman, Hastings, Isaacson, Lewis [Page 67] Job Monitoring MIB, V0.81 April 24, 1997 If the jmAttributeValueAsInteger object is not used (no 'INTEGER:' tag), the agent shall return the value (-1) indicating other. If the jmAttributeValueAsOctets object is not used (no 'OCTETS:' tag), the agent shall return a zero-length octet string." ::= { jmAttributeEntry 1 } jmAttributeInstanceIndex OBJECT-TYPE SYNTAX Integer32(1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A running 16-bit index of the attributes of the same type for each job. For those attributes with only a single instance per job, this index value shall be 1. For those attributes that are a single value per document, the index value shall be the document number, starting with 1 for the first document in the job. Jobs with only a single document shall use the index value of 1. For those attributes that can have multiple values per job or per document, such as documentFormatIndex or documentFormatType, the index shall be a running index for the job as a whole, starting at 1." ::= { jmAttributeEntry 2 } jmAttributeValueAsInteger OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. The value of the attribute shall be represented as an integer if the enum description in the JmAttributeTypeTC definition (see page 27) has the tag: 'INTEGER:'. Depending on the enum definition, this object value may be an integer, a counter, an index, or an enum, depending on the jmAttributeTypeIndex value. The units of this value are specified in the enum description. For those attributes that are accumulating job consumption as the job is processed as specified in the JmAttributeTypeTC, shall contain the final value after the job completes processing, i.e., this value shall indicate the total usage of this resource made by the job. A monitoring application is able to copy this value to a suitable longer term storage for later processing as part of an accounting system. Since the agent may add attributes representing resources to this table while the job is waiting to be processed or being processed, which can be a long time before any of the resources are actually used, the agent shall set the value of the Bergman, Hastings, Isaacson, Lewis [Page 68] Job Monitoring MIB, V0.81 April 24, 1997 jmAttributeValueAsInteger object to 0 for resources that the job has not yet consumed. Attributes for which the concept of an integer value is meaningless, such as fileName, interpreter, and physicalDeviceName, do not have the 'INTEGER:' tag in the JmAttributeTypeTC definition and so shall return a value of (-1) to indicate other for jmAttributeValueAsInteger. For attributes which do have the 'INTEGER:' tag in the JmAttributeTypeTC definition, if the integer value is not (yet) known, the value shall be (-2) to represent unknown or the attribute row shall not be present in the table." ::= { jmAttributeEntry 3 } jmAttributeValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. The value of the attribute shall be represented as an OCTET STRING if the enum description in the JmAttributeTypeTC definition (see page 27) has the tag: 'OCTETS:'. Depending on the enum definition, this object value may be a coded character set string (text) or a binary octet string, such as DateAndTime. Attributes for which the concept of an octet string value is meaningless, such as pagesCompleted, do not have the tag 'OCTETS:' in the JmAttributeTypeTC definition and so shall return a value of a zero length string for the jmAttributeValueAsOctets object." ::= { jmAttributeEntry 4 } -- Conformance Information jmMIBConformance OBJECT IDENTIFIER ::= { jobmonMIB 2 } -- compliance statements jmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the job monitoring MIB." MODULE -- this module MANDATORY-GROUPS { jmGeneralGroup, jmJobIDGroup, jmJobStateGroup, jmAttributeGroup } OBJECT jmJobState SYNTAX INTEGER { processing(5), Bergman, Hastings, Isaacson, Lewis [Page 69] Job Monitoring MIB, V0.81 April 24, 1997 needsAttention(7), canceled(8), completed(9) } DESCRIPTION "It is conformant for an agent to implement just these four states in this object. Any additional states are conditionally mandatory, i.e., an agent shall represent any additional states that the server or device implements. However, a client shall accept all of the states from an agent." -- OBJECT jmAttributeTypeIndex -- SYNTAX INTEGER { -- jobState(3), -- numberOfInterveningJobs(9), -- deviceAlertCode(10), -- jobKOctetsRequested(48), -- jobKOctetsCompleted(50), -- impressionsRequested(54), -- impressionsCompleted(55), -- outputBinName(35) -- } -- DESCRIPTION --"It is conformant for an agent to implement just these 8 -- attributes. Any additional attributes are conditionally -- mandatory, i.e., an agent shall represent any additional -- states that the server or device implements. However, a -- client shall accept all of the attributes from an agent and -- either display them to its user or ignore them. -- -- NOTE - SMI does not allow an enum to be declared as mandatory -- if that enum is not a member of a group, but -- jmAttributeTypeIndex cannot be a member of a group and still -- be not-accessible. So this MIB comments the mandatory -- attributes as if SMI allowed such a declaration in order to -- declare the mandatory attributes." -- There are no conditionally mandatory or optional groups. ::= { jmMIBConformance 1 } jmMIBGroups OBJECT IDENTIFIER ::= { jmMIBConformance 2 } jmGeneralGroup OBJECT-GROUP OBJECTS { jmGeneralNumberOfActiveJobs, jmGeneralOldestActiveJobIndex, jmGeneralNewestActiveJobIndex, jmGeneralJobPersistence, jmGeneralAttributePersistence, jmGeneralJobSetName} STATUS current DESCRIPTION "The general group." ::= { jmMIBGroups 1 } jmJobIDGroup OBJECT-GROUP OBJECTS { Bergman, Hastings, Isaacson, Lewis [Page 70] Job Monitoring MIB, V0.81 April 24, 1997 jmJobSetIndex, jmJobIndex } STATUS current DESCRIPTION "The job ID group." ::= { jmMIBGroups 2 } jmJobStateGroup OBJECT-GROUP OBJECTS { jmJobState, jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, jmJobStateAssociatedValue } STATUS current DESCRIPTION "The job state group." ::= { jmMIBGroups 3 } jmAttributeGroup OBJECT-GROUP OBJECTS { jmAttributeValueAsInteger, jmAttributeValueAsOctets } STATUS current DESCRIPTION "The attribute group." ::= { jmMIBGroups 4 } END Bergman, Hastings, Isaacson, Lewis [Page 71] Job Monitoring MIB, V0.81 April 24, 1997 Appendix A - Job Life Cycle 12. Job Life Cycle The job object has well-defined states and client operations that affect the transition between the job states. Internal server and device actions also affect the transitions of the job between the job states. These states and transitions are referred to as the job's life cycle. Not all implementations of job submission protocols have all of the states of the job model specified here. The job model specified here is intended to be a superset of most implementations. It is the purpose of the agent to map the particular implementation's job life cycle onto the one specified here. The agent may omit any states not implemented. Only the processing, needsAttention, canceled, and completed states are required to be implemented by an agent. However, a management application shall be prepared to accept any of the states in the job life cycle specified here, so that the management application can interoperate with any conforming agent. The job states are intended to be the user visible. The agent shall make these states visible in the MIB, but only for the subset of job states that the implementation has. Implementations may need to have sub-states of these user-visible states. Such implementation is not specified in this model, is not supported by this Job Monitoring MIB, and will vary from implementation to implementation. One of the purposes of the job model is to specify what is invariant from implementation to implementation as far as the MIB specification and the user is concerned. Therefore, job states are all intended to last a user-visible length of time in most implementations. However, some jobs may pass through some states in zero time in some situations and/or in some implementations. The job model does not specify how accounting and auditing is implemented, except to require that accounting and auditing logs are separate from the job life cycle and last longer than job objects. Jobs in the completed state are not logs, since jobs in the completed state are accessible via job submission and/or job management protocol operations and are removed from these job tables after a site-settable period of time. Accounting information may be copied incrementally to the accounting logs as a job processes, or may be copied while the job is in the completed state, depending on implementation. The same is true for auditing logs. The jmJobState object and the jobState attribute both specify the standard job states. The legal job state transitions are shown in the state transition diagram presented in Table 1. An implementation need not support all legal job state transitions. Bergman, Hastings, Isaacson, Lewis [Page 72] Job Monitoring MIB, V0.81 April 24, 1997 Table 12-2 - Legal Job State Transition Table New State "active" jobs unkno hel pend proce prin needsAt cance compl wn d ing ssing ting tention led eted Old state 2 3 4 5 6 7 8 9 unknown(2) yes yes yes yes held(3) yes yes yes yes pending(4) yes yes yes yes processing(5) yes yes yes yes yes printing(6) yes yes yes yes needsAttention(7) yes yes yes yes canceled(8) yes completed(9) yes 13. Bibliography [1] The Printer MIB - RFC 1579, proposed IETF standard. Also an Internet-Draft on the standards track as a draft standard: draft-ietf- printmib-mib-info-01.txt [2] ISO/IEC 10175 Document Printing Application (DPA). See ftp://ftp.pwg.org/pub/pwg/dpa/ [3] Internet Printing Protocol (IPP), in progress on the IETF standards track. See draft-ietf-ipp-model-00.txt. See also http://www.pwg.org/ipp/index.html Bergman, Hastings, Isaacson, Lewis [Page 73] Job Monitoring MIB, V0.81 April 24, 1997 [4] IEEE 1284.1, Transport-independent Printer System Interface (TIPSI). [5] MIB-II, RFC 1213. [6] Host Resources MIB, RFC 1514 14. Author's Addresses Ron Bergman Dataproducts Corp. Phone: 805-578-4421 Fax: Email: rbergman@dpc.com Tom Hastings Xerox Corporation, ESAE-231 701 S. Aviation Blvd. El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 EMail: scott_isaacson@novell.com Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301 Phone: (303) 924-5337 Fax: Email: harryl@us.ibm.com Send comments to: JMP Mailing List: jmp@pwg.org JMP Mailing List Subscription Information: jmp-request@pwg.org Bergman, Hastings, Isaacson, Lewis [Page 74] Job Monitoring MIB, V0.81 April 24, 1997 Other Participants: Chuck Adams - Tektronix Jeff Barnett - IBM Keith Carter, IBM Corporation Jeff Copeland - QMS Andy Davidson - Tektronix Roger deBry - IBM Mabry Dozier - QMS Lee Ferrel - Canon Steve Gebert - IBM Robert Herriot - Sun Microsystems Inc. Shige Kanemitsu - Kyocera David Kellerman - Northlake Software Rick Landau - Digital Harry Lewis - IBM Pete Loya - HP Ray Lutz - Cognisys Jay Martin - Underscore Mike MacKay, Novell, Inc. Stan McConnell - Xerox Carl-Uno Manros, Xerox, Corp. Pat Nogay - IBM Bob Pentecost - HP Rob Rhoads - Intel David Roach - Unisys Hiroyuki Sato - Canon Bob Setterbo - Adobe Gail Songer, EFI Mike Timperman - Lexmark Randy Turner - Sharp William Wagner - Digital Products Jim Walker - Dazel Chris Wellens - Interworking Labs Rob Whittle - Novell Don Wright - Lexmark Lloyd Young - Lexmark Atsushi Yuki - Kyocera Peter Zehler, Xerox, Corp. Bergman, Hastings, Isaacson, Lewis [Page 75] Job Monitoring MIB, V0.81 April 24, 1997 15. INDEX This index includes the textual conventions, the objects, and the attributes. Textual conventions all start with the prefix: "JM" and end with the suffix: "TC". Objects all starts with the prefix: "jm" followed by the group name. Attributes are identified with enums, and so start with any lower case letter and have no special prefix. colorantConsumedIndex, 43 colorantConsumedName, 43 colorantRequestedIndex, 42 colorantRequestedName, 43 deviceAlertCode, 32 deviceNameRequested, 34 documentCopiesCompleted, 38 documentCopiesRequested, 38 documentFormatIndex, 35 documentFormatType, 36 documentName, 35 fileName, 35 finishing, 37 impressionsCompleted, 41 impressionsCompletedCurrentCopy, 41 impressionsInterpreted, 41 impressionsRequested, 41 impressionsSentToDevice, 41 impressionsSpooled, 40 jmAttributeInstanceIndex, 66 jmAttributeTypeIndex, 65 JmAttributeTypeTC, 27 jmAttributeValueAsInteger, 66 jmAttributeValueAsOctets, 67 JmFinishingTC, 21 jmGeneralAttributePersistence, 58 jmGeneralJobPersistence, 58 jmGeneralJobSetName, 58 jmGeneralNewestActiveJobIndex, 57 jmGeneralNumberOfActiveJobs, 56 jmGeneralOldestActiveJobIndex, 57 jmJobIndex, 61 JmJobServiceTypesTC, 44 jmJobSetIndex, 61 JmJobSourcePlatformTypeTC, 21 jmJobState, 62 jmJobStateAssociatedValue, 63 jmJobStateImpressionsCompleted, 63 jmJobStateKOctetsCompleted, 63 JmJobStateReasons1TC, 45 JmJobStateReasons2TC, 48 JmJobStateReasons3TC, 53 JmJobStateReasons4TC, 54 JmJobStateTC, 24 jmJobSubmissionIDIndex, 60 JmMediumTypeTC, 23 Bergman, Hastings, Isaacson, Lewis [Page 76] Job Monitoring MIB, V0.81 April 24, 1997 JmPrintQualityTC, 23 JmTimeStampTC, 20 JmTonerEconomyTC, 23 jobAccountName, 33 jobComment, 35 jobCompletedDateAndTime, 44 jobCompletedTimeStamp, 44 jobCopiesCompleted, 38 jobCopiesRequested, 38 jobHoldUntil, 37 jobKOctetsCompleted, 40 jobKOctetsRequested, 39 jobKOctetsTransferred, 39 jobName, 32 jobOwner, 33 jobPriority, 36 jobProcessAfterDateAndTime, 36 jobProcessingCPUTime, 44 jobServiceTypes, 33 jobSourceChannelIndex, 34 jobSourcePlatformType, 34 jobStartedBeingHeldTimeStamp, 43 jobStartedProcessingDateAndTime, 43 jobStartedProcessingTimeStamp, 44 jobState, 30 jobStateAssociatedValue, 30 jobStateReasons1, 31 jobStateReasons2, 31 jobStateReasons3, 31 jobStateReasons4, 31 jobSubmissionToDeviceDateAndTime, 43 jobSubmissionToDeviceTimeStamp, 43 jobSubmissionToServerDateAndTime, 43 mediumConsumedName, 42 mediumRequestedName, 42 mediumRequestedType, 42 numberOfDocuments, 35 numberOfInterveningJobs, 32 other, 29 outputBinIndex, 37 outputBinName, 37 pagesCompleted, 41 pagesCompletedCurrentCopy, 41 pagesRequested, 41 physicalDeviceIndex, 35 physicalDeviceName, 35 printQualityRequested, 37 printQualityUsed, 37 processingMessage, 32 queueNameRequested, 34 serverAssignedJobName, 32 sheetsCompleted, 42 sheetsCompletedCurrentCopy, 42 sheetsRequested, 42 Bergman, Hastings, Isaacson, Lewis [Page 77] Job Monitoring MIB, V0.81 April 24, 1997 sides, 37 submittingApplicationName, 34 submittingServerName, 34 tonerDensityRequested, 38 tonerDensityUsed, 38 tonerEcomonyRequested, 38 tonerEcomonyUsed, 38 unknown, 30 Bergman, Hastings, Isaacson, Lewis [Page 78]