JP1 Version 12 JP1/Automatic Job Management System 3 System Design (Configuration) Guide

3021-3-D22-30(E)

Notices

Relevant program products

For details about the applicable OS versions, and the service packs and patches required for JP1/Automatic Job Management System 3, see the Release Notes.

JP1/Automatic Job Management System 3 - Manager (For Windows):

P-2A12-3KCL JP1/Automatic Job Management System 3 - Manager version 12-60

The above product includes the following:

P-CC2A12-4KCL JP1/Automatic Job Management System 3 - Manager version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC2912-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC8212-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC2A12-3NCL JP1/Automatic Job Management System 3 - Print Option Manager version 12-50 (For Windows Server 2019, Windows Server 2016, Windows Server 2012)

JP1/Automatic Job Management System 3 - Manager (For HP-UX):

P-1J12-3KCL JP1/Automatic Job Management System 3 - Manager version 12-60

The above product includes the following:

P-CC1J12-4KCL JP1/Automatic Job Management System 3 - Manager version 12-60 (For HP-UX(IPF))

P-CC2912-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC8212-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC1J12-3NCL JP1/Automatic Job Management System 3 - Print Option Manager version 12-50 (For HP-UX(IPF))

JP1/Automatic Job Management System 3 - Manager (For Solaris):

P-9D12-3KCL JP1/Automatic Job Management System 3 - Manager version 12-60

The above product includes the following:

P-CC9D12-4KCL JP1/Automatic Job Management System 3 - Manager version 12-60 (For Solaris 11(SPARC))

P-CC2912-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC8212-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC9D12-3NCL JP1/Automatic Job Management System 3 - Print Option Manager version 12-50 (For Solaris 11(SPARC))

JP1/Automatic Job Management System 3 - Manager (For AIX):

P-1M12-3KCL JP1/Automatic Job Management System 3 - Manager version 12-60

The above product includes the following:

P-CC1M12-4KCL JP1/Automatic Job Management System 3 - Manager version 12-60 (For AIX)

P-CC2912-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC8212-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC1M12-3NCL JP1/Automatic Job Management System 3 - Print Option Manager version 12-50 (For AIX)

JP1/Automatic Job Management System 3 - Manager (For Linux):

P-8112-3KCL JP1/Automatic Job Management System 3 - Manager version 12-60

The above product includes the following:

P-CC8112-4KCL JP1/Automatic Job Management System 3 - Manager version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC2912-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012)

P-CC8212-39CL JP1/Automatic Job Management System 3 - Web Console version 12-60 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

P-CC8112-3NCL JP1/Automatic Job Management System 3 - Print Option Manager version 12-50 (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7)

JP1/Automatic Job Management System 3 - Agent (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012):

P-2A12-33CL JP1/Automatic Job Management System 3 - Agent version 12-60

JP1/Automatic Job Management System 3 - Agent (For HP-UX(IPF)):

P-1J12-33CL JP1/Automatic Job Management System 3 - Agent version 12-60

JP1/Automatic Job Management System 3 - Agent (For Solaris 11 (SPARC)):

P-9D12-33CL JP1/Automatic Job Management System 3 - Agent version 12-60

JP1/Automatic Job Management System 3 - Agent (For AIX):

P-1M12-33CL JP1/Automatic Job Management System 3 - Agent version 12-60

JP1/Automatic Job Management System 3 - Agent (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7):

P-8112-33CL JP1/Automatic Job Management System 3 - Agent version 12-60

JP1/Automatic Job Management System 3 - Agent Minimal Edition (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012):

P-2A12-38CL JP1/Automatic Job Management System 3 - Agent Minimal Edition version 12-60

JP1/Automatic Job Management System 3 - Agent Minimal Edition (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7):

P-8112-38CL JP1/Automatic Job Management System 3 - Agent Minimal Edition version 12-60

JP1/Automatic Job Management System 3 - View (For Windows):

P-2A12-34CL JP1/Automatic Job Management System 3 - View version 12-50

The above product includes the following:

P-CC2A12-44CL JP1/Automatic Job Management System 3 - View version 12-50 (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows Server 2012, Windows 7)

P-CC2A12-3MCL JP1/Automatic Job Management System 3 - Print Option version 12-50 (For Windows Server 2019, Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows Server 2012, Windows 7)

JP1/Base (For Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012):

P-2A2C-6LCL JP1/Base version 12-50

JP1/Base (For HP-UX(IPF)):

P-1J2C-6LCL JP1/Base version 12-50

JP1/Base (For Solaris 11 (SPARC)):

P-9D2C-6LCL JP1/Base version 12-50

JP1/Base (For AIX):

P-1M2C-6LCL JP1/Base version 12-50

JP1/Base (For Linux 6.1(x64) or later, Linux 7.1, Oracle Linux 6(x64), Oracle Linux 7, SUSE Linux 12, CentOS 6(x64), CentOS 7):

P-812C-6LCL JP1/Base version 12-50

Trademarks

HITACHI, JP1, Job Management Partner 1, uCosminexus, HiRDB are either trademarks or registered trademarks of Hitachi, Ltd. in Japan and other countries.

Active Directory is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

AIX is a trademark of International Business Machines Corporation, registered in many jurisdictions worldwide.

Excel is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

IBM is a trademark of International Business Machines Corporation, registered in many jurisdictions worldwide.

MQSeries is a trademark of International Business Machines Corporation, registered in many jurisdictions worldwide.

Internet Explorer is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

Itanium is a trademark of Intel Corporation or its subsidiaries.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Microsoft is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Outlook is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

Pentium is a trademark of Intel Corporation or its subsidiaries.

Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries.

SQL Server is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

UNIX is a trademark of The Open Group.

Windows is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

Windows Server is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries.

All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc., in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.

Other company and product names mentioned in this document may be the trademarks of their respective owners.

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

This product includes software developed by Ben Laurie for use in the Apache-SSL HTTP server project.

Portions of this software were developed at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign.

This product includes software developed by the University of California, Berkeley and its contributors.

This software contains code derived from the RSA Data Security Inc. MD5 Message-Digest Algorithm, including various modifications by Spyglass Inc., Carnegie Mellon University, and Bell Communications Research, Inc (Bellcore).

Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. The original software is available from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

This product includes software developed by Ralf S. Engelschall <rse@engelschall.com> for use in the mod_ssl project (http://www.modssl.org/).

1. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)

2. This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)

3. This product includes software written by Tim Hudson (tjh@cryptsoft.com)

4. This product includes the OpenSSL Toolkit software used under OpenSSL License and Original SSLeay License. OpenSSL License and Original SSLeay License are as follow:

LICENSE ISSUES

==============

The OpenSSL toolkit stays under a double license, i.e. both the conditions of

the OpenSSL License and the original SSLeay license apply to the toolkit.

See below for the actual license texts. Actually both licenses are BSD-style

Open Source licenses. In case of any license issues related to OpenSSL

please contact openssl-core@openssl.org.

OpenSSL License

---------------

/* ====================================================================

* Copyright (c) 1998-2018 The OpenSSL Project. All rights reserved.

*

* Redistribution and use in source and binary forms, with or without

* modification, are permitted provided that the following conditions

* are met:

*

* 1. Redistributions of source code must retain the above copyright

* notice, this list of conditions and the following disclaimer.

*

* 2. Redistributions in binary form must reproduce the above copyright

* notice, this list of conditions and the following disclaimer in

* the documentation and/or other materials provided with the

* distribution.

*

* 3. All advertising materials mentioning features or use of this

* software must display the following acknowledgment:

* "This product includes software developed by the OpenSSL Project

* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

*

* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to

* endorse or promote products derived from this software without

* prior written permission. For written permission, please contact

* openssl-core@openssl.org.

*

* 5. Products derived from this software may not be called "OpenSSL"

* nor may "OpenSSL" appear in their names without prior written

* permission of the OpenSSL Project.

*

* 6. Redistributions of any form whatsoever must retain the following

* acknowledgment:

* "This product includes software developed by the OpenSSL Project

* for use in the OpenSSL Toolkit (http://www.openssl.org/)"

*

* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY

* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR

* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT

* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)

* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,

* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)

* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED

* OF THE POSSIBILITY OF SUCH DAMAGE.

* ====================================================================

*

* This product includes cryptographic software written by Eric Young

* (eay@cryptsoft.com). This product includes software written by Tim

* Hudson (tjh@cryptsoft.com).

*

*/

Original SSLeay License

-----------------------

/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)

* All rights reserved.

*

* This package is an SSL implementation written

* by Eric Young (eay@cryptsoft.com).

* The implementation was written so as to conform with Netscapes SSL.

*

* This library is free for commercial and non-commercial use as long as

* the following conditions are aheared to. The following conditions

* apply to all code found in this distribution, be it the RC4, RSA,

* lhash, DES, etc., code; not just the SSL code. The SSL documentation

* included with this distribution is covered by the same copyright terms

* except that the holder is Tim Hudson (tjh@cryptsoft.com).

*

* Copyright remains Eric Young's, and as such any Copyright notices in

* the code are not to be removed.

* If this package is used in a product, Eric Young should be given attribution

* as the author of the parts of the library used.

* This can be in the form of a textual message at program startup or

* in documentation (online or textual) provided with the package.

*

* Redistribution and use in source and binary forms, with or without

* modification, are permitted provided that the following conditions

* are met:

* 1. Redistributions of source code must retain the copyright

* notice, this list of conditions and the following disclaimer.

* 2. Redistributions in binary form must reproduce the above copyright

* notice, this list of conditions and the following disclaimer in the

* documentation and/or other materials provided with the distribution.

* 3. All advertising materials mentioning features or use of this software

* must display the following acknowledgement:

* "This product includes cryptographic software written by

* Eric Young (eay@cryptsoft.com)"

* The word 'cryptographic' can be left out if the rouines from the library

* being used are not cryptographic related :-).

* 4. If you include any Windows specific code (or a derivative thereof) from

* the apps directory (application code) you must include an acknowledgement:

* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"

*

* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND

* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE

* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL

* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS

* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)

* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT

* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY

* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

* SUCH DAMAGE.

*

* The licence and distribution terms for any publically available version or

* derivative of this code cannot be changed. i.e. this code cannot simply be

* copied and put under another distribution licence

* [including the GNU Public Licence.]

*/

This product includes software developed by the Java Apache Project for use in the Apache JServ servlet engine project (http://java.apache.org/).

This product includes software developed by IAIK of Graz University of Technology.

This product includes software developed by Daisuke Okajima and Kohsuke Kawaguchi (http://relaxngcc.sf.net/).

This product includes software developed by Andy Clark.

Java is a registered trademark of Oracle and/or its affiliates.

Microsoft product name abbreviations

This manual uses the following abbreviations for Microsoft product names.

Abbreviation

Full name or meaning

Excel

Microsoft(R) Excel

Microsoft(R) Office Excel

Exchange Server

Microsoft(R) Exchange 2000 Enterprise Server

Microsoft(R) Exchange 2000 Server

Microsoft(R) Exchange Server

IE

Internet Explorer

Microsoft(R) Internet Explorer(R)

Windows(R) Internet Explorer(R)

Microsoft SQL Server

Microsoft(R) SQL Server

Microsoft(R) SQL Server Enterprise Edition

MSMQ

Microsoft(R) Message Queue Server

Outlook

Outlook 2010

Microsoft(R) Office Outlook(R) 2010

Outlook 2013

Microsoft(R) Office Outlook(R) 2013

Outlook 2016

Microsoft(R) Office Outlook(R) 2016

Outlook 2019

Microsoft(R) Office Outlook(R) 2019

Outlook Express

Microsoft(R) Outlook(R) Express

Windows 10

Windows(R) 10 Enterprise

Windows(R) 10 Pro

Windows(R) 10 Home

Windows 7

Microsoft(R) Windows(R) 7 Enterprise

Microsoft(R) Windows(R) 7 Professional

Microsoft(R) Windows(R) 7 Ultimate

Windows 8

Windows(R) 8 Enterprise

Windows(R) 8 Pro

Windows 8.1

Windows(R) 8.1 Enterprise

Windows(R) 8.1 Pro

Windows Server 2012

Windows Server 2012

Microsoft(R) Windows Server(R) 2012 Datacenter

Microsoft(R) Windows Server(R) 2012 Standard

Windows Server 2012 R2

Microsoft(R) Windows Server(R) 2012 R2 Datacenter

Microsoft(R) Windows Server(R) 2012 R2 Standard

Windows Server 2016

Microsoft(R) Windows Server(R) 2016 Datacenter

Microsoft(R) Windows Server(R) 2016 Standard

Windows Server 2019

Microsoft(R) Windows Server(R) 2019 Datacenter

Microsoft(R) Windows Server(R) 2019 Standard

Windows Server 2022

Microsoft(R) Windows Server(R) 2022 Datacenter

Microsoft(R) Windows Server(R) 2022 Standard

Windows is sometimes used generically, referring to Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows Server 2012, and Windows 7.

Restrictions

Information in this document is subject to change without notice and does not represent a commitment on the part of Hitachi. The software described in this manual is furnished according to a license agreement with Hitachi. The license agreement contains all of the terms and conditions governing your use of the software and documentation, including all warranty rights, limitations of liability, and disclaimers of warranty.

Material contained in this document may describe Hitachi products not available or features not available in your country.

No part of this material may be reproduced in any form or by any means without permission in writing from the publisher.

Issued

Jan. 2022: 3021-3-D22-30(E)

Copyright

Copyright (C) 2019, 2022, Hitachi, Ltd.

Copyright (C) 2019, 2022, Hitachi Solutions, Ltd.

Colophon

Publisher

Hitachi, Ltd.

6-6, Marunouchi 1-chome, Chiyoda-ku, Tokyo, 100‒8280 Japan

Summary of amendments

For details about the amendments, see the manual JP1/Automatic Job Management System 3 Overview.

Preface

This manual describes system design based on JP1/Automatic Job Management System 3 (abbreviated hereafter to JP1/AJS3). Read this manual in conjunction with the manual JP1/Automatic Job Management System 3 Overview, which describes the functionalities of JP1/AJS3.

For details on the prerequisites before reading this manual, see the manual JP1/Automatic Job Management System 3 Overview.

Organization of this manual

This manual organized into the following chapters. The manual is a common reference for all supported operating systems. Any platform-dependent differences in functionality are noted in the manual.

1. Overview of System Design

Chapter 1 describes the design flow and points to consider when deploying JP1/AJS3.

2. Designing the System Configuration

Chapter 2 describes how to configure a system based on JP1/AJS3.

3. Estimates

Chapter 3 describes how to estimate the JP1/AJS3 processing performance and system performance, and the size of the database area and output log files.

4. Installation and Setup Considerations

Chapter 4 explains the settings required when installing and setting up JP1/AJS3.

5. Contingency Planning

Chapter 5 discusses matters to consider when planning backup and recovery measures in case of failures.

6. Maintenance Planning

Chapter 6 describes the database maintenance tasks to be considered, and discusses when to schedule them.

7. Special Modes of Operation

Chapter 7 discusses matters to consider when using QUEUE jobs and submit jobs, or when using queueless jobs.

8. Migration from a Previous Version

Chapter 8 describes how to migrate from JP1/AJS2, and provides cautionary notes when upgrading.

9. Notes on System Design

Chapter 9 summarizes points to note when designing a JP1/AJS3 system.

1 Overview of System Design

This chapter describes the design flow and points to consider when deploying JP1/AJS3.

1.1 Design flow

The design flow when deploying JP1/AJS3 can be broadly categorized as a work-task design for automating job execution under JP1/AJS3, and a system design for installing and running JP1/AJS3 efficiently.

The following figure shows the basic design steps when you deploy JP1/AJS3.

Figure 1‒1: JP1/AJS3 design steps

This manual describes system design. It covers decisions you need to make during the system life-cycle design phase to install and operate JP1/AJS3 efficiently. You will need to determine the system and network configuration, estimate disk space requirements, and work out backup and troubleshooting measures.

For details about work task design, see the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide. For details about changing settings after starting operation, see the JP1/Automatic Job Management System 3 Administration Guide.

1.2 Key decisions in the system design stage

The following table lists the key decisions in the system design stage, and the relevant chapters in this manual.

Table 1‒1: System design decisions and relevant chapters

No.

Key decisions

Relevant chapter

1

System configuration, network configuration, job execution environment, and database requirements

2. Designing the System Configuration

2

Estimates:

Computer performance

System resources

Sizes of database area and log files

Kernel parameters

3. Estimates

3

Required JP1/AJS3 environment settings (parameters) for building the system

4. Installation and Setup Considerations

4

Contingency measures such as backups and redundancy

5. Contingency Planning

5

Database maintenance

6. Maintenance Planning

6

Use of QUEUE jobs, submit jobs, and queueless jobs

7. Special Modes of Operation

7

Migration and version compatibility

8. Migration from a Previous Version

8

Other matters related to system design

9. Notes on System Design

1.3 Design considerations

This section covers the following system design considerations:

Preparatory estimates and settings for running JP1/AJS3

Operations that might affect JP1/AJS3 system operation

1.3.1 Preparatory estimates and settings for running JP1/AJS3

The following describes items you will need to estimate or set in advance for running JP1/AJS3, and points to consider when doing so.

Table 1‒2: Preparatory estimates and settings for running JP1/AJS3

Item

Considerations

Action

Further information

Jobs

Total number of jobs per day

Estimate whether the system can handle the total number of jobs.

As a general rule, keep the number of jobs executed per day to no more than 10,000.

Even a well-designed system would be unable to process more than 50,000 to 100,000 jobs per day.

Reduce the number of jobs. We recommend no more than 10,000 jobs per day. Allow for reruns in case of job execution errors.

3.1.1 Job throughput

Number of jobs per hour at peak times

Estimate whether the system can handle the number of jobs at peak times. The limit is 5,000 per hour.

Reduce the number of jobs. We recommend no more than 500 to 1,000 jobs per hour. Allow for reruns in case of job execution errors.

3.1.1 Job throughput

Number of jobs when automatic retries are specified for jobs

Estimate the number of jobs, including the number of retry executions.

For example, if a maximum of five retries is set for a job, estimate the number of jobs as six (the original execution plus five retry executions).

Take the number specified for Maximum retry times into account. We recommend no more than 500 to 1,000 jobs per hour, and no more than 10,000 jobs per day.

3.1.1 Job throughput

Whether to use the standard output file, standard error output file, and file transfer

This affects the CPU load, memory usage, and job execution performance.

Try to keep the standard output file, standard error output file, and transferred files as small as possible.

7.10.1 Notes on the standard output file and standard error output file in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

Whether to append data to the standard output file and standard error output file as each job is executed

Appending data will increase the size of the files as each job is executed, causing problems such as increased CPU load when files are transferred.

If data is to be appended at each job execution, we recommend some measure such as periodically deleting the output files.

7.10.1 Notes on the standard output file and standard error output file in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

Maximum number of concurrently executable jobs

In Windows, be careful of jobs that take a long time to execute.

Due to the limitations of the desktop heap, the maximum number of executable jobs cannot be increased significantly in Windows. If jobs take a long time to execute and the maximum number is reached, you will need to take measures such as distributing the processing among multiple agents.

2.5.4 Maximum number of concurrently executable jobs, and

4.2.3 Changing the JP1/AJS3 service settings (Windows only)

Jobnets

Number of root jobnets executed per day

As a general rule, register no more than 4,000 jobnets for execution per day.

If the maximum is exceeded, allocate the root jobnets among multiple scheduler services.

4.3.2 Activating multiple scheduler services concurrently

Number of defined jobnets

Reduce the number of root jobnets.

When a large number of root jobnets contain only a few lower units, combine them into a single root jobnet wherever possible.

7.1 Notes on the number of root jobnets registered for execution in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

Job group hierarchies

As a general rule, keep the number of root jobnets in a job group to no more than 500.

Jobnet hierarchies

Create 2 or 3 levels of hierarchy, including the root jobnet, because more complex hierarchies result in reduced visibility.

Jobnet structure

Allow no more than 50-100 nested jobnets and jobs to be defined in one root jobnet or nested jobnet. Make sure that no more than approximately 500 nested jobnets and jobs are located below one root jobnet.

Number of logs to keep

Generations of execution results exceeding the set limit will be deleted when a root jobnet is executed. This affects the root jobnet's start performance.

Reduce the number of root jobnets that can be registered, bearing in mind that saved generations exceeding the limit will be deleted when the root jobnet is executed.

7.2 Relationship between number of logs to keep and performance in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

This affects the database size, response time, and resources.

Keep as few generations of data as your system will allow.

Jobnet and job operation

Continuous operation

If performed continuously, operations that place a high load on the scheduler service will further increase the system load, which could affect system operations.

Avoid continuous operations that entail jobnet or job execution. Pause for 2-3 seconds between each operation.

1.3.2 Operations that might affect JP1/AJS3 system operation, and

1.2 Notes on using commands in the manual JP1/Automatic Job Management System 3 Command Reference

Number of lower units

The amount of information to be processed increases in proportion to the number of lower units. This could affect system operations.

When the number of lower units exceeds 500, execute the jobnet when the work-load is low.

Wildcard characters in commands

If a command is executed with wildcard characters, the number of information items to process might increase, which might affect system operations.

Restrict the number of units targeted by the command before executing the command, such as by directly specifying the units that would be targeted by executing the command with wildcard characters.

Number of logs to keep

Operating on a jobnet that has many generations of execution results increases the amount of information to be processed. This could affect system operations.

If the target jobnet has a large number of generations, perform the operation when the work-load is low. Specify options to limit the time period and number of generations.

When canceling registration of a jobnet, you can also specify an option that deletes generations one by one.

Start conditions

Whether to use start conditions

Jobs with start conditions are used for transaction processing purposes and have a significant effect on the number of jobs being executed.

Accurately estimate the number of events issued and the peak traffic.

3.1.5 Event monitoring performance

Event jobs

Timing of monitoring JP1 event reception monitoring jobs

The status of the JP1 event-reception monitoring job must be Monitoring to receive JP1 events.

To link jobnets using a JP1 event, register the JP1 event-reception monitoring job at a set time before the JP1 event is sent.

7.6.1 Notes on the Receive JP1 Event job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

Number of Monitoring Files jobs

This has a significant effect on CPU performance and the response time for Monitoring Files jobs.

When monitoring files over a network, the network performance is also affected.

Determine the file monitoring interval, using the equation in 3.1.6 Monitoring interval set when using the Monitoring Files job, and extend the monitoring interval accordingly.

3.1.6 Monitoring interval set when using the Monitoring Files job

Monitoring frequency

This has a significant effect on CPU performance and the response time for Monitoring Files jobs.

When monitoring files over a network, the network performance is also affected.

Extend the monitoring interval as appropriate.

Number of files monitored by Monitoring Files jobs

Timing of updates to files monitored by Monitoring Files jobs

Monitoring Files jobs cannot monitor files that are frequently opened and closed to append data.

Consider solutions such as creating and updating a separate file from the file that was last updated.

7.6.2 Notes on the Monitoring Files job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide

JP1/AJS3 - View

Automatic update

By default, displayed contents are updated automatically, and a database access request is generated on the manager host at every update.

The update interval is 300 seconds for the JP1/AJS3 - View window and Daily Schedule window, and 30 seconds for the Jobnet Monitor window. If performance is paramount, set a larger update interval or disable automatic update.

4.5.5 Setting the window display

Monthly Schedule window and Daily Schedule window

The number of display items and the amount of data transferred to the Monthly and Daily Schedule windows increases with the number of jobnets being monitored and the number of schedules.

Make sure that you complete the performance estimates in advance.

3.2.1 Estimating the data flow on the network

Number of connections

The load on JP1/AJS3 - Manager and on the network increases when more than 63 instances of JP1/AJS3 - View are connected.

Set a larger update interval or disable automatic update.

B. List of Limits

1.3.2 Operations that might affect JP1/AJS3 system operation

The following table gives details about the job and jobnet operations in Table 1-2 that might affect the JP1/AJS3 system.

Table 1‒3: List of operations that might affect JP1/AJS3 system operation

Operation

Type of operation

Command

JP1/AJS3 - View

JP1/AJS3 - Web Console

Continuous operation

Number of lower units

Wildcard characters specification#1

Number of logs to keep

ajsbackup

Backup

(N/A)

--

Yes

Yes

--

ajscalendar

Calendar

(N/A)

Yes

--

Yes

--

ajschange

Editor

(N/A)

Yes#2

--

Yes

--

ajschgjob

Editor

(N/A)

--

--

Yes

--

ajschgnet

Editor

(N/A)

Yes#2

--

Yes

--

ajschgstat

Change status

Change job status

Yes

--

Yes

--

ajscopy

Copy

(N/A)

--

Yes

Yes

--

ajsdefine

New

(N/A)

--

Yes

--

--

ajsdelete

Delete

(N/A)

--

Yes

Yes

--

ajsentry

Register

Register

Yes

Yes

Yes

--

ajsexport

Package

(N/A)

--

Yes

--

--

ajsimport

Package

(N/A)

--

Yes

--

--

ajsintrpt

Interrupt

Interrupt

Yes

--

Yes

--

ajskill

Kill

Kill

Yes

--

Yes

--

ajsleave

Cancel registration

Cancel registration

Yes

Yes

Yes

Yes

ajsname

(N/A)

(N/A)

--

--

Yes

--

ajsplan

Change plan

Add

Change plan

Change hold attribute

Change delay monitor

Yes

--

Yes

--

ajsprint

Execute the command from JP1/AJS3 - View

(N/A)

--

Yes

Yes

--

ajsrelease

Release entry

(N/A)

Yes

Yes

--

--

Release cancel

(N/A)

Yes

Yes

--

--

ajsrerun

Rerun

Rerun

Yes

Yes

Yes

--

ajsrestore

Restore

(N/A)

--

Yes

--

--

ajsrgexport

(N/A)

(N/A)

--

Yes

Yes

--

ajsrgimport

(N/A)

(N/A)

Yes

Yes

--

--

ajsschedule

(N/A)

(N/A)

--

Yes

--

Yes

ajsshow

Daily schedule; Monthly schedule

Execute the command from JP1/AJS3 - View

Dashboard; Monthly schedule

--

Yes

Yes

Yes

Legend:

(N/A): No applicable operations

Yes: The operation might affect JP1/AJS3 operation.

--: Not applicable.

#1: Limited to command operations.

#2: When changing a schedule.

For notes on executing commands, see 1.2.3 Notes on commands that consume a large amount of system resources or commands that perform mutually conflicting processes in the manual JP1/Automatic Job Management System 3 Command Reference.

2 Designing the System Configuration

This chapter describes how to configure a system for using JP1/AJS3.

Based on where jobs and jobnets will be executed and other such considerations, decide which of the JP1/AJS3 series programs to install on which computers.

2.1 Checking the operating environment

This section describes the operating environments and prerequisites required by each of the programs and components that comprise the JP1/AJS3 suite.

2.1.1 JP1/AJS3 series programs

This subsection describes the JP1/AJS3 series programs.

JP1/AJS3 - Manager

This program manages jobnet definition information and schedule information, and requests agents (JP1/AJS3 - Agent or JP1/AJS3 - Manager) to execute processing. JP1/AJS3 - Manager can also execute processes itself.

A maximum of 1,024 agent hosts can be connected to one JP1/AJS3 - Manager (or to one logical host in a cluster configuration). You can increase the maximum number of agent hosts to 2,048. This maximum includes an agent on the local host.

Two JP1/AJS3 - Managers can be inter-connected, allowing execution of jobs by another JP1/AJS3 - Manager, and execution of work tasks linked to a job executed by another JP1/AJS3 - Manager.

Using JP1/AJS3 - Web Console, you can also monitor the work tasks via the Internet.

JP1/AJS3 - Agent

This program executes processing in response to execution requests from JP1/AJS3 - Manager.

JP1/AJS3 - Agent functionality includes job execution in an agent role, event job monitoring, and action job execution.

JP1/AJS3 - Agent Minimal Edition

This program allows for a maximum of 10 jobs to be executed by request from JP1/AJS3 - Manager.

JP1/AJS3 - Agent Minimal Edition has the same functionality as JP1/AJS3 - Agent, except for some limitations. For details, see G. Using JP1/AJS3 - Agent Minimal Edition.

JP1/AJS3 - View

This program enables you to operate JP1/AJS3 - Manager through a graphical user interface.

A maximum of 128 JP1/AJS3 - View programs can be connected to one JP1/AJS3 - Manager at the same time.

2.1.2 JP1/AJS3 prerequisites

This subsection indicates the OSs and programs that are prerequisites for the JP1/AJS3 series programs.

(1) Prerequisite operating systems

The following table lists the OSs that can run JP1/AJS3 series programs.

Table 2‒1: OSs that can run JP1/AJS3 series programs

OS

JP1/AJS3 - Manager

JP1/AJS3 - Web Console

JP1/AJS3 - Agent

JP1/AJS3 - View

Windows Server 2022

Yes

Yes

Yes

Yes

Windows Server 2019

Yes

Yes

Yes

Yes

Windows Server 2016

Yes

Yes

Yes

Yes

Windows 10

--

--

--

Yes

Windows 8.1

--

--

--

Yes

Windows 8

--

--

--

Yes

Windows Server 2012

Yes

Yes

Yes

Yes

Windows 7

--

--

--

Yes

HP-UX (IPF)

Yes

--

Yes#

--

Solaris

Yes

--

Yes#

--

AIX

Yes

--

Yes#

--

Linux

Yes

Yes

Yes

--

Legend:

Yes: Can run

--: Cannot run

#

JP1/AJS3 - Agent Minimal Edition cannot run.

(2) Prerequisite programs

The following table lists the programs that are required for using JP1/AJS3 programs.

Table 2‒2: Prerequisite programs

JP1/AJS3 series program

Prerequisite program

JP1/AJS3 - Manager

JP1/Base

JP1/AJS3 - Web Console

--

JP1/AJS3 - Agent

JP1/Base

JP1/AJS3 - View

--

Legend:

--: Not necessary

(3) Prerequisite browsers

One of the following browsers is required to use the Web GUI. For details about supported versions, see the Release Notes.

Internet Explorer

Firefox ESR

Google Chrome

Microsoft Edge

Tip

The Web GUI can now be used with Firefox for smart devices (iPad and iPhone) within the scope of compatibility with the preceding web browsers in PC environments. For notes applicable to smart device environments, see C Notes on using the Web GUI in a smart device environment in the JP1/Automatic Job Management System 3 Operator's Guide.

(4) Other prerequisites

For details about restrictions such as limit values in a JP1/AJS3 system configuration and supported characters, see B. List of Limits.

2.2 Determining the system configuration

With JP1/AJS3, you can use a whole range of system configurations, from systems where jobs can be managed and executed on a single host to large-scale systems that execute a large number of jobs on multiple hosts. JP1/AJS3 can also be deployed on multi-platform systems.

2.2.1 Example of a system configuration for executing work tasks on a single host

Work tasks can be centrally managed and executed on a single host on which JP1/AJS3 - Manager is installed.

JP1/AJS3 - View can also be installed on the manager host, allowing jobs to be managed, executed, and monitored using the GUI. Alternatively, jobs can be managed, executed, and monitored by connecting to the manager host from JP1/AJS3 - View on another host.

The following figure shows an example of a standalone system with JP1/AJS3 - Manager and JP1/AJS3 - View installed on a single host.

Figure 2‒1: Example of a standalone system configuration

2.2.2 Examples of manager/agent system configurations

Jobs can be distributed among multiple hosts. Install JP1/AJS3 - Manager on the hosts on which jobs will be managed (one or more manager hosts) and JP1/AJS3 - Agent on the hosts on which the jobs will be executed (agent hosts). JP1/AJS3 - Manager can be used instead of JP1/AJS3 - Agent. Install JP1/AJS3 - View on the hosts that will perform job monitoring.

(1) Operation with a single manager host

Install JP1/AJS3 - Manager on the manager host, and JP1/AJS3 - Agent on the agent hosts. Set up a dedicated JP1/AJS3 - View host as required.

The following figure shows an example of a manager/agent system configuration with one manager host.

Figure 2‒2: Example of a manager/agent system configuration (one manager host)

(2) Operation with multiple manager hosts

Prepare multiple hosts on which to install JP1/AJS3 - Manager, and multiple hosts on which to install JP1/AJS3 - Agent. Set up a dedicated JP1/AJS3 - View host as required.

The following figure shows an example of a manager/agent system configuration with multiple manager hosts.

Figure 2‒3: Example of a manager/agent system configuration (multiple manager hosts)

Use JP1/AJS3 in an environment where the IP address can be resolved from the local host name. JP1/AJS3 can only operate in an environment where the IP address can be resolved from the local host name.

When executing jobs on multiple agent hosts, you must also specify settings that allow resolution of the IP addresses for the manager hosts, agent hosts, and the hosts in other systems. When DNS is used, specify settings that allow resolution of host names in the FQDN format. Note, however, that host names in the FQDN format cannot be used for logical host names.

(3) Using a single agent host as multiple execution hosts

To execute jobs in JP1/AJS3, you must register agent host information in the manager host. The required information consists of the execution agent (the logical name of the agent host), together with its physical host name.

By creating multiple execution agents (logical names) for a single agent host, you can set up a job execution environment in which a single agent host can be used as multiple execution hosts. For details, see 2.5 Setting the job execution environment.

(4) Notes on manager/agent system configurations

Some cautions on manager/agent configurations are listed below.

Communication between manager and agent hosts is based on the host names of the hosts. Specify the settings so that the manager host name can be correctly resolved on the agent hosts and the agent host names can be correctly resolved on the manager host.

Hereafter, Host names refers to names that can be checked by using the methods below.

Physical host:

The name found by executing the hostname command on a JP1/AJS3 host

Logical host (Windows)

On the host on which JP1/AJS3 is running, in Control Panel, by choosing Services or Administrative Tools, and then Services. In the Services dialog box that opens, the host name is displayed in the xxxxx portion of JP1/AJS3_xxxxx.

Logical host (UNIX)

Executing the ps command. The host name is displayed after the jajs_spmd process.

Depending on the manager/agent configurations, the now queuing status of standard jobs, HTTP connection jobs, action jobs, custom jobs, or event jobs might not change. If this problem occurs, check whether any of conditions below are satisfied. If any are satisfied, review the system settings.

When an agent host name cannot be resolved on a manager host, or a manager host name cannot be resolved on an agent host

Configure the hosts file, DNS server, jp1hosts information, or jp1hosts2 information on each manager host and agent host so that each manager host can resolve the host names of agent hosts and each agent host can resolve the host names of manager hosts. For details about how to define the jp1hosts information and jp1hosts2 information, see the JP1/Base User's Guide.

The following shows an example of specifying the hosts file settings.

Figure 2‒4: Example of hosts file entries that enable hosts to resolve each other's host names

An alias for an agent host name is defined on the manager host. For this reason, the IP address obtained from the host name displayed by the hostname command executed on the agent host is not the same as the IP address obtained from the host name specified in the alias definition.

The following shows an example of specifying hosts file entries.

Figure 2‒5: Example of specifying the hosts file entries when an alias is used for a host name

The agent host name is defined in FQDN format in the hosts file on the manager host, but the host name displayed by the hostname command executed on the agent host is a short name. Alternatively, the agent host name in the hosts file is defined with a short name, but the host name displayed by the hostname command is in FQDN format. In either case, the host name cannot be resolved on the manager host.

The following shows an example of a host name that cannot be resolved.

Figure 2‒6: Example of a host name in FQDN format defined in the hosts file

Figure 2‒7: Example of a short host name defined in the hosts file

In the above cases, the communication sequence for the job between the manager and agent is not completed even if the job can be executed. As a result, a large amount of retry data, which could cause the following problems, might remain on the manager and agent:

- Load on the system becomes heavy. Jobs that the user attempted to execute might not be removed from the queue, event detection might be extremely delayed, or the system might be unable to detect events.

- When the JP1/AJS3 service is restarted on the agent host, events that were detected in the past are detected again.

The second problem occurs when the remaining retry data includes data that reports detection of an event since that report data is sent to the manager again when the agent is restarted.

If these problems occur, stop the JP1/AJS3 service between the manager host and the agent host, and then specify settings so that both the host name and the short name can be resolved mutually between the manager host and the agent host. Next, cold-start the JP1/AJS3 service on the manager host and on the agent host. If necessary, register the jobnet for execution again.

Set name resolution so that an IP address other than the loopback address (127.0.0.1) is preferentially assigned to the physical host. However, if it is necessary to assign the loopback address due to operating requirements, configure the jp1hosts information or jp1hosts2 information to assign an IP address that allows the physical host to communicate with other hosts. For details about how to define the jp1hosts information or jp1hosts2 information, see the JP1/Base User's Guide.

A manager and agent are connected via a network. The procedure for the retry process if a network error occurs while a job is being executed is indicated in the table below.

Table 2‒3: Job retry process if a network error occurs

Job type

Retry processing

PC jobs, Unix jobs, flexible jobs#1, HTTP connection jobs, QUEUE jobs, action jobs, custom jobs

Retry from a manager to an agent

The manager retries twice at a monitoring interval of 300 seconds#2.

Retry from an agent to a manager

The agent retries forwarding the job result file 2 times (in 10 minutes) at a send retry interval of 300 seconds.#3

Event jobs

Retry from a manager to an agent

If the manager cannot connect to the agent host (a timeout error occurs), the manager retries 27 times (in 24 hours) at the send retry interval of 300 seconds, 600 seconds, 900 seconds, 1,800 seconds, and 3,600 seconds (and every 3,600 seconds after this).#4

For network errors other than those above, the manager retries 2,880 times (in 24 hours) at the send retry interval of 30 seconds.#5

Retry from an agent to a manager

The agent retries 8,640 times (in 24 hours) at the send retry interval of 10 seconds.#5

Queueless jobs (PC jobs, Unix jobs, action jobs)

No retries

#1

For flexible jobs, replace agent with relay agent. Note that transfer from a relay agent to a destination agent is not retried.

#2

This is the default for ObserveInterval, the environment setting parameter for job execution control, which sets the interval for monitoring the job execution agents.

#3

The send retry interval and maximum number of retries can be changed as needed for the operation. For details, with Windows hosts, see 6.2.5 Changing the interval and number of resend attempts for job result files in the JP1/Automatic Job Management System 3 Configuration Guide. For details with UNIX hosts, see 15.2.5 Changing the interval and number of resend attempts for job result files in the JP1/Automatic Job Management System 3 Configuration Guide.

#4

You can specify the setting so that if the manager is unable to connect to the agent host, a timeout error occurs and the manager retries the transfer at the interval defined for errors other than timeout errors. For details, see 6.3.11 Settings for ensuring that the sending of unreported information is retried at regular intervals in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.11 Settings for ensuring that the sending of unreported information is retried at regular intervals in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

#5

You can change the retry interval and maximum number of retries to values that are best suited for system operation. For details, see 6.3.12 Changing the send retry interval and the number of retries for sending unreported information in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.12 Changing the send retry interval and the number of retries for sending unreported information in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

When a network error has occurred, job execution is delayed by the monitoring time only, and operation continues. However, if a network error continues for longer than the monitoring time indicated above, Failed to start is output as the job execution result.

When the error message KAVU2227-E (A connection error occurred during TCP/IP communication.) is output, all the socket ports might be busy in the entire system. If this happens, take the following corrective action.

On a Windows host:

Execute the netstat -a command to investigate the system's socket status, and check whether there are a lot of sockets placed in the TIME_WAIT status. If they are, there might be temporary shortages of available socket ports. If a communication error message is output, job execution and job status confirmation might have failed because it was not possible to make a socket connection. In this case, rerun the job when the number of sockets in the TIME_WAIT status has decreased.

Note that you can prevent communication errors from occurring by speeding up recovery of TIME_WAIT sockets managed in Windows. The procedure for this is as follows.

1. Execute the following command to start the Registry Editor:

C:\> regedt32.exe

2. Open the following TCP/IP registry key:

\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. Add the following registry values:

Name: TcpTimedWaitDelay

Data type: REG_DWORD

Data: Any value (decimal notation)

4. Restart Windows.

You can specify any required value for the TcpTimedWaitDelay parameter. Set a value that is appropriate for the operating environment.

The standard value is 120 seconds and the minimum value is 30 seconds.

On a UNIX host:

If there are a lot of sockets placed in the TIME_WAIT status, there might be temporary shortages of available socket ports. If a communication error message is output, job execution and job status confirmation might have failed because it was not possible to make a socket connection. In this case, rerun the job when the number of sockets in the TIME_WAIT status has decreased.

JP1/AJS3 - Manager polls the status of PC jobs, Unix jobs, HTTP connection jobs, QUEUE jobs, action jobs, and custom jobs running on agent hosts in five-minute intervals. JP1/AJS3 - Manager polls the status of flexible jobs running on a relay agent in five-minute intervals, but does not monitor the execution status on destination agents.

When polling cannot be performed for 10 minutes or more because of a communication error or power outage at the executing host (agent), for example, the job status is changed. Jobs executed in a jobnet are placed in abnormal end status (return code: -1). Jobs executed by a jpqjobsub command change their status as specified in the command's -rs option.

If the agent stops while an event job is running, the status of the event job depends on how the agent was stopped and whether the option to continue execution of active event jobs is being used.

If an event job is registered for execution while the agent is stopped, the system retries the job start request at predetermined intervals. For the job statuses for each agent termination status, see 6.2.1(4) Job statuses on the manager host when an agent host is restarted in the JP1/Automatic Job Management System 3 Administration Guide.

For details about the option to continue execution of active event jobs, see 8.2.1 Continuing the execution of event jobs if the JP1/AJS3 service stops in the JP1/Automatic Job Management System 3 Administration Guide. For details about the event job retry process, see Table 2-3.

If multiple IP addresses are assigned to an agent host, the event/action control manager can manage a maximum of four IPv4 addresses and four IPv6 addresses per host. Make sure that each host has four or fewer IPv4 addresses and four or fewer IPv6 addresses.

If more than four IPv4 addresses can be obtained from a host name, the event/action control manager manages only four of the obtained addresses. However, no rules exist about which addresses are managed. The situation is the same when more than four IPv6 addresses are obtained from a host name.

When you define an alias HostB for an agent host with the real host name HostA, make sure that the same IP address is returned for both the real host name and the alias.

2.2.3 Example of a system configuration for creating a cluster system

A cluster system comprises multiple server systems linked to operate as a single system. Two servers with the same environment are set, and if a fault occurs in the server that executes work tasks (the primary node system) the processing is passed to another server (the secondary node server) and the work task is continued.

The following figure shows an example of a system configuration for creating a cluster system.

Figure 2‒8: Example of a system configuration for creating a cluster system

When you are considering which system configuration to use for cluster operation, note that logical host names in FQDN format cannot be used in a cluster system.

For details about the setup for using a cluster system, see 8. Setup for Operation in a Cluster System in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows hosts), or 17. Setup for Operation in a Cluster System in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX hosts).

For details about operating a cluster system, see 10. Operation in a Cluster System in the JP1/Automatic Job Management System 3 Administration Guide.

2.2.4 Configuration example for disaster recovery operation

For the disaster recovery supported by JP1/AJS3, a system that has the same environment as the system that is operating regularly is set up at a remote site, and the updated contents of the shared disk for the regular system are copied to the shared disk at the remote site. This arrangement allows you to prepare for a large-scale disaster or other unexpected events. Use the disk copy and mirroring functionality of the hardware to copy data between the shared disks.

In JP1/AJS3 disaster recovery, the system that is operating regularly is called the main site, and the system located at a separate remote site is called the remote site.

The following figure shows an example of a system configuration for the disaster recovery supported by JP1/AJS3.

Figure 2‒9: Example of a system configuration for disaster recovery supported by JP1/AJS3 (Cluster configuration, shared agent type)

For details about the system configuration or the procedure for performing disaster recovery operation, see 11. Disaster Recovery in JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

For details about the disaster recovery setup, see 9. Setup Required for Disaster Recovery Operation in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows) or 18. Setup Required for Disaster Recovery Operation in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX).

Depending on the method of connection, a LAN connection might be required between the main-site host and remote-site host. Depending on the hardware you use, you might also need to install software before you can use the copy and mirroring functionality between shared disks at the main and the remote sites. For details, see the documentation for the hardware.

2.2.5 Examples of system configurations that include a Web Console server

A Web Console server must be installed if you want to monitor units using the Web GUI or a user application. The following sections describe examples of system configurations with a Web Console server.

(1) The Web Console server and the manager host run on the same host

In this configuration, JP1/AJS3 - Manager and JP1/AJS3 - Web Console are installed on a single host.

The Web GUI or a user application can be used as a client along with JP1/AJS3 - View.

Note that this configuration can only be made when the host OS is Windows or Linux.

Figure 2‒10: Example of a system configuration in which the Web Console server and the manager host run on the same host

(2) The Web Console server and the manager host run on different hosts

In this configuration, JP1/AJS3 - Manager and JP1/AJS3 - Web Console are installed on separate hosts.

The Web GUI or a user application can be used as a client along with JP1/AJS3 - View.

Figure 2‒11: Example of a system configuration in which the Web Console server and the manager host run on different hosts

(3) The Web Console server is placed in the DMZ

Consider placing the Web Console server in the DMZ when the Web GUI or a user application is connected via the Internet using HTTP. This enables a more secure system configuration.

Figure 2‒12: Example 1 of a system configuration in which the Web Console server is placed in the DMZ

Figure 2‒13: Example 2 of a system configuration in which the Web Console server is placed in the DMZ

2.3 Determining the network configuration

This section describes matters you need to consider with regard to network configurations.

2.3.1 Network configurations that are supported by JP1/AJS3

JP1/AJS3 supports the following network configurations:

Multiple LAN connections

Use of firewalls

IPv6 addresses (Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012, and Linux only)

SSL communications

Check the following when setting up the network configuration of a server running JP1/AJS3:

NIC grouping

Many OSs provide the ability to group together two or more NICs, enabling you to fail over to a backup NIC when one NIC fails. Examples include NIC teaming in Windows, Multipath in Solaris, and EtherChannel in AIX. When you use these NIC grouping features on servers running JP1, their operation must be transparent to JP1 and have no effect on its operation.

JP1/AJS3 communication settings are based on the JP1/Base communication settings. JP1/Base is the prerequisite program for JP1/AJS3, and its communication settings can be changed to accommodate a variety of network configurations. To change the communication settings, use the jp1hosts definition file or jp1hosts2 definition file, and the communication protocol settings file. Note that the network configurations of JP1/AJS3 - Manager and JP1/AJS3 - Agent are based on these communication settings.

For details about the JP1/Base communication settings, see the chapter on JP1/Base communication protocols and the chapter on JP1/Base communication settings based on network configurations in the JP1/Base User's Guide.

Cautionary notes

JP1/AJS3 - View and JP1/AJS3 - Web Console do not support the functionality for changing JP1/Base communication protocol settings. To enable communication from JP1/AJS3 - View or JP1/AJS3 - Web Console to JP1/AJS3 - Manager by specifying the host name of the manager host, use the hosts file or DNS information.

Note that when an OS allows multiple IP addresses to be resolved from a single host name, the event/action control function and the job execution control function operate differently depending on whether the communication protocol for multiple LAN connections has been set for JP1/Base.

When the communication protocol for multiple LAN connections has not been set for JP1/Base

Resolved IP addresses are used one after another until a connection is successfully established.

When the communication protocol for multiple LAN connections has been set for JP1/Base

A connection is attempted only to the resolved IP address at the beginning of the jp1hosts definition file or the jp1hosts2 definition file.

JP1/AJS3 does not perform correctly in an environment where IP addresses are changed dynamically and the destination host changes. Run JP1/AJS3 in an environment where a unique host name and IP address can be determined. However, if the host is used as the destination agent for a flexible job, JP1/AJS3 can run in an environment where IP addresses are changed dynamically.

Because embedded databases do not conform to the JP1/Base communication settings, you will need to use OS functionality to resolve the physical host name or logical host name to an IP address.

If JP1/AJS3 - Manager version 10-00 or later was used to set up the embedded database, use the loopback address (127.0.0.1) for communication within the embedded database and between the JP1/AJS3 - Manager and the embedded database.

JP1/AJS3 does not work properly in an environment where the same destination host name is duplicated on hosts that are connected to multiple networks. Make sure that the host names used for communication are unique, and that unique IP addresses can be obtained from the host names.

The following figure shows an example of an environment where the same destination host name is duplicated on hosts that are connected to multiple networks.

Figure 2‒14: Example of a host name being duplicated on hosts that are connected to multiple networks

In the example above, the same host name, HostA, is used in LAN_A and in LAN_B. As a result, HostB is unable to determine whether HostA corresponds to LAN_A or LAN_B.

If you want to disable NIC (Network Interface Card) to resolve a network failure or some other issue, stop the JP1/AJS3 service before disabling NIC.

Problems occur if you disable NIC without stopping the JP1/AJS3 service. For example, jobs do not start, or job statuses are not updated.

The following table shows the support status of communication settings for the functionalities provided by JP1/AJS3.

Table 2‒4: Support status of communication settings for the functionality provided by JP1/AJS3

Functionality

Communication settings

jp1hosts definition file or jp1hosts2 definition file

Communication protocol settings file

PC jobs

Unix jobs

QUEUE jobs

Passing information setting jobs

Submit jobs

Y

Y

Custom jobs

Y#2

Y#2

Queueless jobs

Y

--#3

Flexible jobs

Y#4

Y#4

HTTP connection jobs

Y#5

Y#5

Judgment jobs

NC

NC

OR jobs

NC

NC

Event jobs#1

Receive JP1 Event job

Y (NC)

Y (NC)

Monitoring Files job

Y (NC)

Y (NC)

Receive Mail job

Y (--)

Y (--)

Receive MQ Message job

Y (NC)

Y (NC)

Receive MSMQ Message job

Y (--)

Y (--)

Monitoring Log Files job

Y (NC)

Y (NC)

Monitoring Event Log job

Y (NC)

Y (NC)

Interval Control job

Y (NC)

Y (NC)

Action jobs#1

Send JP1 Event job

Y (Y#6, #7)

Y (Y#6)

Send Mail job

Y (--)

Y (--)

Send MQ job

Y (--)

Y (--)

Send MSMQ message job

Y (--)

Y (--)

OpenView Status Report job

Y (--)

Y (--)

Local Power Control job

Y (Y#8, #9)

Y (--)

Remote Power Control job

Y (Y#6, #7, #8, #9)

Y# (Y#6, #8)

Jobnet connector

Y#10

Y#10

Remote jobnets

Y

Y

Schedule execution

NC

NC

Remote execution of commands

Y

Y

Legend:

Y: Supported

--: Not supported

NC: No communication

#1

Y, --, and NC indicate whether the communication setting applies for communication between manager and agent hosts. Y (Y), Y (--), and Y (NC) indicate whether the communication setting with the linked program applies when an event job or an action job is executed.

#2

Supported for communication between the manager hosts and the agent hosts, but the status of support for the communication settings of a program to which a custom job links depends on that program.

#3

ANY binding is set for the receive setting. The Communication protocol settings file is supported for the send setting.

#4

Supported for communication between the manager host and the relay agent, but not supported for communication with the destination agent, the broadcast agent, and the destination agent at the broadcast destination.

#5

Supported for communication between the manager hosts and the agent hosts, but not supported for communication between the agent hosts and the web server.

#6

The support status is based on the event server settings file (conf) of JP1/Base. For details, see the description of Definition Files in the JP1/Base User's Guide.

#7

The support status is based on the API settings file (api) of JP1/Base. For details, see the description of Definition Files in the JP1/Base User's Guide.

#8

Not supported for communication with the power control.

#9

JP1/Power Monitor for UNIX does not support the jp1hosts definition file or the jp1hosts2 definition file. JP1/Power Monitor for Windows supports the jp1hosts definition file and the jp1hosts2 definition file. Note that the communication functionality of JP1/Power Monitor for Windows depends on the JP1PW_USE_JP1HOSTS environment setting parameter.

#10

This indicates whether communication settings can be specified when the execution order of root jobnets of different scheduler services is to be controlled. The jobnet connector does not communicate to control the execution order of root jobnets of the same scheduler services.

2.3.2 Firewall and communication basics

When you use JP1 in a network environment that includes a firewall, you must consider the following two firewall functionalities:

Access restriction (packet filtering)

Allow only necessary communication, and prevent invalid communications.

Network address translation (NAT)

IP addresses are translated so that direct connections are not possible; connections are made to a network with a different address. The existence of the computer that translates IP addresses is concealed from outsiders.

To set an environment with these considerations, you must understand the method by which the firewall controls communications.

This subsection covers basic knowledge related to firewalls and communications, including packet filtering and NAT. For details about communication settings required for using JP1/AJS3 in an environment with a firewall, see 2.3.4 Communications in firewall environments.

Supplementary note

The explanation given here is an overview to help you understand the basics of firewalls. You must read and properly understand the firewall documentation and reference works on security before attempting to plan and make the security settings for a firewall.

(1) Packet filtering

Packet filtering restricts the communications that are allowed to pass through a firewall. By checking each of the communications packets that pass through the firewall one by one and destroying packets that do not match the predetermined data-passing conditions, invalid communications are prevented from passing through the firewall. This means that only the packets specified in the data-passing conditions will be available behind the firewall.

JP1/AJS3 supports packet filtering.

(a) Setting packet filtering

To set packet filtering:

Investigate the method of communications (the port number that the application uses and so on).

Check the port number, IP address and data-passing direction to be set as firewall data-passing conditions.

Check the communications conditions for JP1/AJS3 by referring to the explanation in this subsection and the explanation in A. List of Port Numbers.

Set data-passing conditions for the firewall.

First block all data packets, and then set passing conditions to allow only specific packets to pass through the firewall.

In JP1/AJS3, specify settings that will allow JP1 communications checked using the procedure described above to pass through the firewall.

(b) Example of Settings for JP1/AJS3

This example shows how to set packet filtering in an environment in which a firewall is placed between JP1/AJS3 - View and JP1/AJS3 - Manager.

Example: Connect JP1/AJS3 - View to JP1/AJS3 - Manager through the firewall.

JP1/AJS3 - Manager is operating in a non-cluster system.

100.100.100.10 is set as the IP address of the computer running JP1/AJS3 - View.

200.200.200.20 is set as the IP address of the computer running JP1/AJS3 - Manager.

The default port number for JP1 is used.

Figure 2‒15: Example of setting packet filtering with JP1/AJS3

Investigate the method of communications for JP1

First, find out the method of communications of JP1; this is required information for setting packet filtering. If you see 2.3.4(2) JP1/AJS3 communications below, you find see that the port numbers that JP1/AJS3 - View uses are explained in tables like the one below.

Table 2‒5: Communications between JP1/AJS3 - View and JP1/AJS3 - Manager

JP1/AJS3 - View

Direction

JP1/AJS3 - Manager

ANY

>>

20244/tcp (jp1ajs2monitor)

This table indicates the following methods of communication:

JP1/AJS3 - Manager accepts connections from JP1/AJS3 - View using port number 20244. In other words, JP1/AJS3 - View is connected to port number 20244 on the JP1/AJS3 - Manager side.

Port number 20244 is defined with the service name jp1ajs2monitor. You can change the port number to a number other than 20244 in the environment settings.

The port number at the JP1/AJS3 - View side is automatically assigned by the OS as any port number that is available at the time (ANY).

The direction of the connection is from JP1/AJS3 - View to JP1/AJS3 - Manager. This direction setting is used when you want to restrict the direction in which data passes through the firewall, for example only permitting connections from network A to network B.

The protocol is TCP.

TCP involves bi-directional communication, and there are outward (JP1/AJS3 - View >> JP1/AJS3 - Manager) and return (JP1/AJS3 - View << JP1/AJS3 - Manager) communications. The outward and return communication packets are designated by the terms Source and Destination.

The available IP addresses depend on the communication settings in JP1/Base. For details, see the JP1/Base User's Guide.

Set packet filtering.

Based on the checked method of communications between JP1/AJS3 - View and JP1/AJS3 - Manager, configure the system so that only these communications can pass through the firewall.

The following table shows the data-passing conditions for packet filtering.

Table 2‒6: Example filtering conditions (for JP1/AJS3 - View and JP1/AJS3 - Manager)

No.

SourceAddress

DestinationAddress

Protocol

SourcePort

DestinationPort

Control

1

100.100.100.10

200.200.200.20

TCP

(ANY)

20244

Accept

2

200.200.200.20

100.100.100.10

TCP

20244

(ANY)

Accept

3

(ANY)

(ANY)

(ANY)

(ANY)

(ANY)

Reject

This table shows the conditions for checking packets and the control if there is a match with the conditions. The Control column indicates whether passage through the firewall is accepted or rejected.

Set the packet filtering of the firewall in accordance with the filtering conditions in this table.

The details of the setting method differ for individual firewalls. See the documentation for your firewall.

(2) NAT (Network Address Translator)

NAT translates private IP addresses to global IP addresses and vice versa. Translating the addresses conceals the private addresses from outsiders, increasing the internal security of the computer.

In addition to its use in firewalls, the NAT functionality is also used with routers.

JP1/Base and JP1/AJS3 support NAT in static mode (addresses are translated according to predetermined rules). The following description applies to address translation in static mode only.

Note that JP1/Base and JP1/AJS3 can be used only in an environment in which a unique host name or IP address can be resolved from the host name used for communication. Therefore, JP1/Base and JP1/AJS3 do not support NAT in the dynamic mode (an available number is dynamically assigned to set or change the rules automatically) or NAPT (IP Masquerade, NAT+) that includes the port-translation functionality.

(a) Setting NAT

To set NAT:

Check the IP address to be used.

First, check the IP address that the application uses. This is simple when dealing with a computer that only uses one IP address, but if multiple network adaptors are used (meaning that there is more than one IP address), or if a logical IP address is used in a cluster system, the IP address used differs depending on the application.

In the case of JP1/AJS3, the IP address used in a non-cluster system will be different from that in a cluster system with a logical host setting. For details, see the JP1/Base User's Guide.

Determine and set the address translation rules.

Once you have checked the IP address that the application uses, decide the IP address after translation.

When you have decided the address translation rules, set them for NAT.

(b) Example setting with JP1/AJS3

The following explains NAT setting for JP1 in a configuration with a firewall between JP1/AJS3 - View and JP1/AJS3 - Manager.

Example: Connecting from JP1/AJS3 - View to a JP1/AJS3 - Manager host with a translated address

JP1/AJS3 - Manager operates in a non-cluster system.

100.100.100.10 is set as the IP address of the JP1/AJS3 - View computer.

150.150.150.15 is set as the IP address of the JP1/AJS3 - Manager computer.

The IP address of this JP1/AJS3 - Manager is translated to 200.200.200.20.

After translation, JP1/AJS3 - View connects to 200.200.200.20.

Figure 2‒16: Example of setting NAT with JP1/AJS3

Check the IP address to be used.

Check the IP address used by JP1. This information is required for setting NAT.

Since the system in this example is non-cluster, communications are conducted using an IP address that corresponds to the host name (result of the hostname command).

Determine and set the address translation rule.

Decide the translation rule for translating the IP address of the JP1/AJS3 - Manager computer from 150.150.150.15 to 200.200.200.20 using NAT.

Table 2‒7: Example of a translation rule (translating 150.150.150.15 to 200.200.200.20)

No.

SourceAddress

DestinationAddress

SourceAddress

(Translated)

DestinationAddress

(Translated)

1

(ANY)

200.200.200.20

(ANY)

150.150.150.15

2

150.150.150.15

(ANY)

200.200.200.20

(ANY)

This table shows the correspondence between the source packet and the packet after address translation.

Define this address translation rule in the NAT setting for the firewall.

The precise details of the setting method will differ depending on the firewall and router. See the documentation for the products you are using.

Now, JP1/AJS3 - View does not access the actual address of the computer where JP1/AJS3 - Manager is installed (150.150.150.15) but the address after translation (200.200.200.20).

From JP1/AJS3 - View, it appears as if a JP1/AJS3 - Manager host with the IP address 200.200.200.20 is being accessed.

(3) Communication settings for using JP1 in a firewall environment

When using a network environment that goes through a firewall, consider the effects of setting "IP bind" as the JP1 communication method for setting multiple LAN connections.

To use JP1 in an environment with a firewall, you must set conditions for packet filtering and NAT in accordance with the IP address and port number, as explained previously. For that reason, use the IP bind method determined by the JP1 settings to clearly establish the JP1 IP addresses.

For example, when JP1 runs in a cluster system or on a server connected to multiple LANs, because the IP address is determined by the OS, an unintended IP address might be used. You can remedy this situation by setting the IP bind method as the JP1 communications method so that communications use the IP address specified in the JP1 environment settings.

2.3.3 Connecting multiple LANs

JP1/AJS3 supports system configurations where JP1/AJS3 - Manager, JP1/AJS3 - Agent, or JP1/AJS3 - View is installed in a server (host) and multiple LANs are connected to this server (host).

To be able to use JP1/AJS3, you need to define one of the following in order to obtain IP addresses from the host names of the connection target hosts:

DNS server

hosts file

jp1hosts file or jp1hosts2 file

The following figure shows an example of a system configuration for communicating with a host connected to multiple LANs.

Figure 2‒17: Example of a system configuration for communicating with a host connected to multiple LANs

In this configuration, you need to specify settings so that when HostA attempts to acquire the IP address of HostB, it acquires the LANA_B IP address. Similarly, specify settings so that when HostC attempts to acquire the IP address of HostB, it acquires the LANB_B IP address.

Assuming that the above prerequisites are met, the following are tips for using JP1/AJS3 on a host connected to multiple LANs.

Whether the communication protocol for multiple LAN connections has been set for JP1/Base

If the communication protocol for multiple LAN connections has been set for the JP1/Base communication setting, the JP1/AJS3 communication protocol is determined by this setting. See (1) Communication protocols for sending or receiving data and (2) Methods for resolving host names to make sure you can use JP1/AJS3 with the current settings.

Whether to set multiple LAN connections if the communication protocol for multiple LAN connections for JP1/Base has not been set

The following are important considerations regarding the JP1/Base communication settings:

Selection of the communication protocol for sending or receiving data

Host name resolution methods (defining jp1hosts information or jp1hosts2 information)

For details about JP1/Base multiple LAN connections, see the description about using JP1/Base in a dissociated network environment in the JP1/Base User's Guide.

(1) Communication protocols for sending or receiving data

The table below shows the communication protocols that are available after JP1/AJS3 has been set up. The communication protocol varies according to whether multiple LAN connections provided by JP1/Base have been set in advance. For details about how to check the current settings, see the description of the JP1/Base communication protocols in the JP1/Base User's Guide.

The following table explains communication protocols available after JP1/AJS3 has been set up.

Table 2‒8: Communication protocols available after JP1/AJS3 has been set up

Communication protocol for physical hosts

Communication protocol for logical hosts

Send

Receive

Send

Receive

Multiple LAN connections have not been set#1

Immediately after installation

ANY binding

ANY binding

--

--

Immediately after cluster setup

IP binding

IP binding#2

IP binding

IP binding#2

Multiple LAN connections have been set#1

Immediately after installation

Same as JP1/Base

Same as JP1/Base#2

--

--

Immediately after cluster setup

Same as JP1/Base

Same as JP1/Base#2

Same as JP1/Base

Same as JP1/Base#2

Legend:

--: Not applicable

#1

Note that when an OS that allows the user to acquire multiple IP addresses from a single host name is used, the event/action control function and the job execution control function operate differently as follows.

When the communication protocol for multiple LAN connections has not been set for JP1/Base

Acquired IP addresses are used one after another until a connection is successfully established.

When the communication protocol for multiple LAN connections has been set for JP1/Base

Of the obtained IP addresses, a connection is attempted only to the IP address at the beginning in the jp1hosts file or jp1hosts2 file.

#2

ANY binding is used for the JP1/AJS3 Queueless Agent and JP1/AJS3 Check Agent services.

If IP binding is set for the transmission setting, data can be sent to only one LAN. In the configuration example shown in Figure 2-17, if the HostB transmission setting is IP binding, HostB can communicate with either LANA or LANB. For this reason, use ANY binding for the transmission setting of a host connected to multiple LANs, irrespective of whether cluster operation is used. When only physical hosts are used, you do not need to specify the setting because ANY binding is set immediately after installation. In a cluster system, you must set the communication protocol for multiple LAN connections of JP1/Base because IP binding is set immediately after cluster setup.

When ANY binding is set for the receive setting in a cluster system, data sent to a physical host might be received by a logical host, or data sent to a logical host might be received by a physical host. As a result, jobs cannot be executed correctly. To avoid this problem, IP binding must be set for the receive setting, irrespective of whether the host is connected to multiple LANs. The setting cannot be changed to ANY binding.

When IP binding is set for the receive setting, only data from a single host can be received. In the configuration example shown in Figure 2-17, if the HostB receive setting is IP binding, HostB can receive data from either HostA or HostC. When the communication protocol for multiple LAN connections of JP1/Base is specified, data from both LANA and LANB can be received as long as the receive setting is IP binding. Accordingly, if you want to set IP binding for the HostB receive setting, the communication protocol for multiple LAN connections of JP1/Base must be set on HostB.

The following table summarizes the above discussion.

Table 2‒9: Whether changes in the communication protocol for JP1/AJS3 are required

Connection to multiple LANs

No

Yes

Operation using physical hosts only

No problem occurs if the setting specified immediately after installation is used.

No problem occurs if the setting specified immediately after installation is used.

Cluster operation

No problem occurs if the setting specified immediately after cluster setup is used.

The communication protocol for multiple LAN connections of JP1/Base must be considered.

Even for the cases in the above table for which there is no problem, you can permanently assign the LAN to be used for JP1/AJS3 by setting the communication protocol for multiple LAN connections of JP1/Base as necessary.

When JP1/AJS3 - Manager, JP1/AJS3 - Agent, and JP1/AJS3 - View are used in an environment in which multiple LANs are connected, the necessary settings vary according to the host on the LAN where a product is used. For details about these settings, see D. Communication Settings in Multiple-LAN Environments.

(2) Methods for resolving host names

For a host connected to multiple LANs, multiple IP addresses must be obtained from a single host name. In the configuration example shown in Figure 2-17, the LANA_B and LANB_B IP addresses must be acquirable as the IP addresses of HostB. However, depending on the OS, it might not be possible to acquire multiple IP addresses from a single host name. In addition, if the hosts use the same hosts file or DNS, and HostC attempts to acquire the IP address of HostB, the LANA_B IP address might be acquired but the LANB_B IP address might not be.

Even in these cases, you can obtain multiple IP addresses from a single host name for JP1/AJS3 communications by defining the jp1hosts information or jp1hosts2 information provided by JP1/Base. As a result, when HostC obtains the IP address of HostB, HostC can also obtain the IP address of LANB_B.

For details about jp1hosts and jp1hosts2, see the JP1/Base User's Guide.

2.3.4 Communications in firewall environments

JP1/AJS3 can be used in system configurations in which JP1/AJS3 - Manager, JP1/AJS3 - Agent, or JP1/AJS3 - View is connected through a firewall.

The following figure shows an example of a system configuration in which a firewall is set.

Figure 2‒18: Example of a system configuration with firewall

(1) JP1/Base communications

For details about JP1/Base communications, see the JP1/Base User's Guide.

(2) JP1/AJS3 communications

The following explains the port numbers, IP addresses, and address translation (NAT) that can be used in JP1/AJS3 communications.

(a) Port numbers

JP1/AJS3 port numbers

JP1/AJS3 uses the following port numbers. In addition to these, the port numbers of JP1/Base, which must be used with JP1/AJS3, are also used.

For JP1/AJS3 port numbers, see A.1 Tables of port numbers.

Major system configurations and communications

This subsection describes major system configurations and communications.

Consult the following references in conjunction with the explanation given here.

References

Explanation of firewall data-passing directions in the JP1/Base User's Guide.

A.2 Directions of traffic through a firewall

Cautionary note

When using JP1 on a firewalled host, set the firewall so that data can pass through all the ports that JP1 uses for communications within the local host. This allows JP1 processes within the local host to communicate using the ports.

The following example system configuration shows the port numbers used and the direction of the communications.

Figure 2‒19: Example system configuration

JP1/AJS3 - View on HOST-V is used to connect HOST-M1.

HOST-M1 and HOST-M2 execute jobs together.

HOST-A is set as the agent of HOST-M1.

HOST-AUTH is set as the authentication server for HOST-M1.

JP1/AJS3 - Web Console on HOST-WEB is used to connect HOST-M1.

The web browser on HOST-CL is used to connect HOST-WEB.

Communications between JP1/AJS3 - View and JP1/AJS3 - Manager

The table below describes the communications between JP1/AJS3 - View and JP1/AJS3 - Manager.

This corresponds to the communications between HOST-V and HOST-M1 in the example system configuration.

Table 2‒10: Communications between JP1/AJS3 - View and JP1/AJS3 - Manager

JP1/AJS3 - View

Direction

JP1/AJS3 - Manager

(ANY)

>>

20244/tcp (jp1ajs2monitor)

Communications between JP1/AJS3 - Manager and JP1/AJS3 - Manager

The table below shows the communications between JP1/AJS3 - Manager and JP1/AJS3 - Manager.

This corresponds to the communications between HOST-M1 and HOST-M2 in the example system configuration.

Table 2‒11: Communications between JP1/AJS3 - Manager and JP1/AJS3 - Manager

JP1/AJS3 - Manager

Direction

JP1/AJS3 - Manager

(ANY)

>>

20241/tcp (jp1ajs2qman)

20242/tcp (jp1ajs2qagt)

20243/tcp (jp1ajs2qnfy)

20244/tcp (jp1ajs2monitor)

20245/tcp (jp1ajs2report)

20246/tcp (jp1ajs2eamgr)

20247/tcp (jp1ajs2eaagt)

20300/tcp (jp1ajs2qlagt)

20301/tcp (jp1ajs2qlftp)

23139/tcp (jp1ajs2chkagt)

23160/tcp (jp1ajs2gw)

20241/tcp (jp1ajs2qman)

20242/tcp (jp1ajs2qagt)

20243/tcp (jp1ajs2qnfy)

20244/tcp (jp1ajs2monitor)

20245/tcp (jp1ajs2report)

20246/tcp (jp1ajs2eamgr)

20247/tcp (jp1ajs2eaagt)

20300/tcp (jp1ajs2qlagt)

20301/tcp (jp1ajs2qlftp)

23139/tcp (jp1ajs2chkagt)

23160/tcp (jp1ajs2gw)

<<

(ANY)

Communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent

The table below shows the communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

This corresponds to the communications between HOST-M1 and HOST-A in the example system configuration.

Table 2‒12: Communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent

JP1/AJS3 - Manager

Direction

JP1/AJS3 - Agent

(ANY)

>>

20242/tcp (jp1ajs2qagt)

20247/tcp (jp1ajs2eaagt)

20300/tcp (jp1ajs2qlagt)

23139/tcp (jp1ajs2chkagt)

20241/tcp (jp1ajs2qman)

20243/tcp (jp1ajs2qnfy)

20246/tcp (jp1ajs2eamgr)

20301/tcp (jp1ajs2qlftp)

<<

(ANY)

Communications between JP1/AJS3 - Manager and JP1/Base (authentication server)

The table below shows the communications between JP1/AJS3 - Manager and JP1/Base (authentication server).

This corresponds to the communications between HOST-M1 and HOST-AUTH in the example system configuration.

Table 2‒13: Communications between JP1/AJS3 - Manager and JP1/Base (authentication server)

JP1/AJS3 - Manager

Direction

JP1/Base

(ANY)

>>

20240/tcp (jp1bsuser)

Communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager

The table below shows the communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager.

This corresponds to the communications between HOST-WEB and HOST-M1 in the example system configuration.

Table 2‒14: Communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager

JP1/AJS3 - Web Console

Direction

JP1/AJS3 - Manager

(ANY)

>>

22250/tcp (jp1ajs3cdinetd)

Communications between JP1/AJS3 - Web Console and a web browser

The table below describes the communications between JP1/AJS3 - Web Console and a web browser.

This corresponds to the communications between HOST-WEB and HOST-CL in the example system configuration.

Table 2‒15: Communications between JP1/AJS3 - Web Console and a web browser

Web browser

Direction

JP1/AJS3 - Web Console

(ANY)

>>

22252/tcp (jp1ajs3web)

22253/tcp (jp1ajs3webssl)

Communications between JP1/AJS3 - Manager, the relay agent, the destination agent, and the broadcast agent

The following table describes the communications between JP1/AJS3 - Manager, relay agent, destination agent, and the broadcast agent when a flexible job is utilized.

Table 2‒16: Communications between JP1/AJS3 - Manager and JP1/AJS3 (relay agent)

JP1/AJS3 - Manager

Direction

JP1/AJS3 - Manager (relay agent), JP1/AJS3 - Agent (relay agent)

(ANY)

>>

20242/tcp (jp1ajs2qagt)

20241/tcp (jp1ajs2qman)

20243/tcp (jp1ajs2qnfy)

<<

(ANY)

Table 2‒17: Communications between JP1/AJS3 (relay agent) and JP1/AJS3 (destination agent)

JP1/AJS3 - Manager (relay agent), JP1/AJS3 - Agent (relay agent)

Direction

JP1/AJS3 - Manager (destination agent), JP1/AJS3 - Agent (destination agent)

(ANY)

>>

22251/tcp (jp1ajs2atmsg)

22251/tcp (jp1ajs2atmsg)

<<

(ANY)

Table 2‒18: Communications between JP1/AJS3 (relay agent) and JP1/AJS3 (broadcast agent)

JP1/AJS3 - Manager (relay agent), JP1/AJS3 - Agent (relay agent)

Direction

JP1/AJS3 - Manager (broadcast agent), JP1/AJS3 - Agent (broadcast agent)

(ANY)

>>

22251/tcp (jp1ajs2atmsg)

22251/tcp (jp1ajs2atmsg)

<<

(ANY)

Table 2‒19: Communications between JP1/AJS3 (broadcast agent) and JP1/AJS3 (destination agent)

JP1/AJS3 - Manager (broadcast agent), JP1/AJS3 - Agent (broadcast agent)

Direction

JP1/AJS3 - Manager (destination agent), JP1/AJS3 - Agent (destination agent)

(ANY)

>>

22251/tcp (jp1ajs2atmsg)

22251/tcp (jp1ajs2atmsg)

<<

(ANY)

(ANY)

>>

22251/udp (jp1ajs2atmsg)

22251/udp (jp1ajs2atmsg)

<<

(ANY)

Communications between JP1/AJS3 and a mail server

The following table describes the communications between JP1/AJS3 and a mail server for mail system linkage without using Outlook.

Table 2‒20: Communications between JP1/AJS3 and a mail server

JP1/AJS3

Direction

Mail server

(ANY)

>>

25/tcp(smtp)

(ANY)

>>

110/tcp(pop3)

(ANY)

>>

587/tcp(Submission Port)

Communications between JP1/AJS3 - Manager and other programs

The following table describes the communications in a different configuration in which other programs (JP1/NQSEXEC and JP1/OJE for VOS3, which are the programs for job cooperation) are utilized.

Table 2‒21: Communications between JP1/AJS3 - Manager and other programs

JP1/AJS3 - Manager

Direction

Other program

(ANY)

>>

20241/tcp (jp1ajs2qman)

20241/tcp (jp1ajs2qman)

20245/tcp (jp1ajs2report)

<<

(ANY)

Cautionary note

Assume that the other program is to receive the status reports on the jobs registered from the other program in JP1/AJS3 - Manager. In such a case, the traffic through the job-status reporting port specified by the other program must be in the direction from JP1/AJS3 - Manager to the other program.

(b) IP address

JP1/AJS3 uses the same IP addresses as JP1/Base. For details, see the JP1/Base User's Guide.

To ensure compatibility among versions, you can select whether the sending side IP address used when executing event jobs corresponds to the sending side IP address or the receiving side IP address used by JP1/Base.

(c) Address translation (NAT)

JP1/AJS3 supports static mode network address translation (NAT).

Cautionary notes

If NAT is used for communication between the agent and the manager, the definition pre-check function cannot correctly check item that category is execution agent name.

The execution order control function (jobnet connector) between scheduler services and within the same host cannot be used via NAT.

(3) Example of configurations that include a firewall, and their communications settings

This subsection describes examples of configurations for cluster and non-cluster operation in environments that include a firewall, and their communication settings.

(a) Example configuration with a firewall for non-cluster operation, and its communications settings

The following explains a configuration for non-cluster operation in a firewall environment, and the communication settings. The following figure shows a configuration example.

Figure 2‒20: Example of a configuration for setting a firewall in a non-cluster system

The firewall is configured so that data passes through it between hostX and hostA. In this system configuration, there is no need to make any special settings in JP1/AJS3 in addition to the settings for the firewall.

(b) Example configuration with a firewall for cluster operation, and its communications settings

The following explains a configuration and communication settings for cluster operation in a firewall environment. The following figure shows a configuration example.

Figure 2‒21: Example of a configuration for setting a firewall in a cluster system

When the firewall is configured so that data passes through it both between hostX and hostA, and between hostL and hostA, as in (a) Example configuration with a firewall for non-cluster operation, and its communications settings above, you do not have to make any special settings in JP1/AJS3.

In a system based entirely on logical hosts with no physical host services, if a firewall is set up only between hostL and hostA, you must set IP bind as the sending method. For details about how to set IP bind, see the chapter about communication settings in the JP1/Base User's Guide.

Cautionary note

If a firewall has not been set to allow communication between hostX (physical host) and hostA, data cannot pass through the firewall when a queueless job is executed. If you are using queueless jobs, set the environment so that data from the physical host can pass through the firewall.

2.3.5 Communication using IPv6 addresses

JP1/AJS3 accommodates communication using IPv6 addresses and communication using both IPv4 addresses and IPv6 addresses. When you migrate the communication environment from an IPv4 address environment to an IPv6 address environment, you can use JP1/AJS3 continuously without changing the system configuration.

For more information, see 2.3.3 Connecting multiple LANs.

(1) Prerequisites for configuring an IPv6 environment

Operation of JP1/AJS3 using IPv6 addresses requires version 10-00 or later of JP1/AJS3 - Manager and JP1/AJS3 - Agent.

JP1/AJS3 - View does not support communication using IPv6 addresses.

Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, and Linux are the only OSs that support communication using IPv6 addresses.

For hosts where JP1/AJS3 - Manager is installed, the IPv4 protocol must be installed and enabled in the system. If the JP1/AJS3 service is started in a system where the IPv4 protocol has not been installed or has been disabled, the KNAD3992-E message is output and the service cannot be started.

Devices that convert IPv4 and IPv6 addresses (protocol translators) cannot be used.

JP1/AJS3 - Web Console does not support communication that uses IPv6 addresses. The IP addresses that can be derived from the connection host names that are specified in the login window or API of JP1/AJS3 - Web Console must be resolved by IPv4.

(2) Overview of communication using IPv6 addresses

JP1/AJS3 uses the communication base function of JP1/Base to obtain an IP address from a host name (normal lookup), to obtain a host name from an IP address (reverse lookup), and to determine the protocol type to be used for ANY binding addresses.

JP1/AJS3 - Manager and JP1/AJS3 - Agent, when needing to use IPv6 addresses to communicate, use the communication base function of JP1/Base to reference jp1hosts2 for the resolution of host names. When host names are correctly resolved to IPv6 addresses, the IPv6 addresses are used to start communications.

Figure 2‒22: Relationship between the communication base function of JP1/Base and JP1/AJS3 when IPv6 addresses are used for communication

For details about the communication base function of JP1/Base, see the JP1/Base User's Guide.

(3) System configuration of hosts using IPv6 addresses

As shown in the following figure, IPv6 environments are network environments that consist of both hosts that communicate with IPv4 addresses and hosts that communicate with IPv6 addresses.

Figure 2‒23: Example system configuration of an IPv6 environment

IPv6 hosts

Hosts that set only the IPv6 address. These hosts cannot communicate using IPv4 addresses.

IPv4 hosts

Hosts that set only the IPv4 address. These hosts cannot communicate using IPv6 addresses.

IPv4/IPv6 hosts

Hosts that set both the IPv4 address and the IPv6 address. These hosts can communicate in either protocol environment.

To communicate using IPv6 addresses in JP1/AJS3, the source host and the destination host must use IP addresses of the same protocol type. Accordingly, when setting up jp1hosts2 or ANY binding addresses, make sure that the IP addresses are the same protocol type and can communicate each other. Note that JP1/AJS3 does not allow communication between different protocols.

The following tables describe the connections between hosts.

Table 2‒22: Connections between manager hosts

Manager host

IPv4 host

IPv6 host

IPv4/IPv6 host

Manager host

IPv4 host

Possible (IPv4)

No

Possible (IPv4)

IPv6 host

No

Possible (IPv6)

Possible (IPv6)

IPv4/IPv6 host

Possible (IPv4)

Possible (IPv6)

Yes

Legend:

Yes: The hosts can communicate using both IPv4 addresses and IPv6 addresses.

Possible (IPv6): The hosts can communicate using only IPv6 addresses.

Possible (IPv4): The hosts can communicate using only IPv4 addresses.

No: No communication is possible.

Table 2‒23: Connections between a manager host and an agent host

Agent host

IPv4 host

IPv6 host

IPv4/IPv6 host

Manager host

IPv4 host

Possible (IPv4)

No

Possible (IPv4)

IPv6 host

No

Possible (IPv6)

Possible (IPv6)

IPv4/IPv6 host

Possible (IPv4)

Possible (IPv6)

Yes

Legend:

Yes: The hosts can communicate using both IPv4 addresses and IPv6 addresses.

Possible (IPv6): The hosts can communicate using only IPv6 addresses.

Possible (IPv4): The hosts can communicate using only IPv4 addresses.

No: No communication is possible.

Table 2‒24: Connections between a manager host and a JP1/AJS3 - View host

JP1/AJS3 - View host

IPv4 host

IPv6 host

IPv4/IPv6 host

Manager host

IPv4 host

Possible (IPv4)

No

Possible (IPv4)

IPv6 host

No

No

No

IPv4/IPv6 host

Possible (IPv4)

No

Possible (IPv4)

Legend:

Possible (IPv4): The hosts can communicate using only IPv4 addresses.

No: No communication is possible.

Table 2‒25: Connections between a client host and a Web Console server

Web Console server

IPv4 host

IPv6 host

IPv4/IPv6 host

Client host

IPv4 host

Possible (IPv4)

No

Possible (IPv4)

IPv6 host

No

No

No

IPv4/IPv6 host

Possible (IPv4)

No

Possible (IPv4)

Legend:

Possible (IPv4): The hosts can communicate using only IPv4 addresses.

No: No communication is possible.

Table 2‒26: Connections between a manager host and a Web Console server

Web Console server

IPv4 host

IPv6 host

IPv4/IPv6 host

Manager host

IPv4 host

Possible (IPv4)

No

Possible (IPv4)

IPv6 host

No

No

No

IPv4/IPv6 host

Possible (IPv4)

No

Possible (IPv4)

Legend:

Possible (IPv4): The hosts can communicate only by using IPv4 addresses.

No: No communication is possible.

When you want IPv4/IPv6 hosts to communicate with each other, assign IP addresses of the same protocol to the hosts. The hosts cannot communicate if only an IPv4 address is assigned to one host and only an IPv6 address is assigned to the other host.

Supplementary note:

Versions 09-50 and earlier of JP1/AJS3 - Manager and JP1/AJS3 - Agent can communicate using only IPv4 addresses. When a host needs to communicate with JP1/AJS3 - Manager or JP1/AJS3 - Agent of an older version, the host must treat the manager host or the agent host as an IPv4 host regardless of the protocol it supports.

Although the IPv4 protocol must be installed and enabled on a host on which JP1/AJS3 - Manager is installed, an IPv4 address does not need to be assigned to the host. Therefore, you can assign only an IPv6 address, and use the host as an IPv6 host.

The following figure shows example system configurations for communication using IPv6 addresses.

Figure 2‒24: Example of system configurations for communication using IPv6 addresses

Configuration example 1 shows an example configuration where multiple manager hosts and agent hosts are connected. Because Mng02 and Agt02 are IPv6 hosts, communication between Mng01 and Mng02, between Mng01 and Agt02, and between Mng02 and Agt01 is not possible. In this configuration, only communication between Mng01 and Agt01 and between Mng02 and Agt02 is possible.

In configuration example 2, a manager host and agent hosts are connected. Mng01 is an IPv4/IPv6 host and can communicate with both Agt01 and Agt02.

Figure 2‒25: Example of an unsupported configuration

Like the configuration above, configurations that have devices that convert IPv4 and IPv6 addresses (protocol translators) between hosts are not supported.

(4) IPv6 addresses that cannot be used

A JP1/AJS3 that uses IPv6 addresses cannot use the following special IPv6 addresses. Design a system configuration that does not use these IPv6 addresses.

Table 2‒27: IPv6 addresses that cannot be used

No.

Type

Description

Example IPv6 address that cannot be used

1

Link-local unicast address

Link-local unicast addresses are valid only on the same subnet (link). The upper 16 bits are fe80.

Link-local unicast addresses cannot be used for JP1/AJS3 IPv6 address communication.

fe80::0123:4567:89ab:cdef

2

IPv4-compatible address

IPv4-compatible addresses are used by IPv4/IPv6 hosts to communicate with one another over an IPv4 network. The upper 96 bits are 0 and the lower 32 bits are the IPv4 address of an IPv4/IPv6 host.

IPv4-compatible addresses cannot be used for JP1/AJS3 IPv6 address communication.

::192.1.2.3

3

IPv4-mapped address

IPv4-mapped addresses are used to represent IPv4 addresses as IPv6 addresses when an IPv4 host communicates with an IPv6 host. The first 80 bits are 0, the next 16 bits are 1, and the remaining 32 bits are the IPv4 address of the IPv4 host.

IPv4-mapped addresses cannot be used for JP1/AJS3 IPv6 address communication.

::ffff:192.1.2.3

4

Unspecified address

For this address, all bits are 0. The unspecified address is used as the source address in the DHCPv6 protocol, but is usually not used.

The unspecified address cannot be used for JP1/AJS3 IPv6 address communication.

::

5

Anycast address

This address is used only as the destination.

To enable anycast communication, assign the same address to multiple interfaces. That address is the anycast address. When a host sends a packet to an anycast address, the packet is sent to the interface nearest the source based on the metrics of the routing protocol.

Anycast addresses cannot be differentiated from global unicast addresses.

Anycast addresses cannot be used for JP1/AJS3 IPv6 address communication.

2001:db80::afff:1

(when used as an anycast address)

6

Multicast address

This address is used only as the destination. The upper 8 bits are 1.

To enable multicast communication, specify a group of interfaces. When a host sends a packet to a multicast address, the packet is sent to all the interfaces in the group.

Multicast addresses cannot be differentiated from global unicast addresses.

Multicast addresses cannot be used for JP1/AJS3 IPv6 address communication.

ff00:1001::abc1

(when used as a multicast address)

7

IPv6 address generated by the automatic stateless address generation function

The automatic stateless address generation function allows an IPv6 host to automatically generate unicast addresses.

IPv6 addresses that are generated by the automatic stateless address generation function cannot be used for JP1/AJS3 IPv6 address communication.

2001:db80::afff:1

(when generated by the automatic stateless address generation function)

(5) Settings for communication using IPv6 addresses

(a) JP1/Base settings for communication using IPv6 addresses

If you want hosts to communicate using IPv6 addresses, you need to specify ANY binding addresses and configure jp1hosts2. If you enable the jp1hosts2 definition, the jp1hosts definition will be disabled. If you want to perform an upgrade installation of JP1/Base from version 09-50 or earlier to version 10-00 or later, you need to migrate the definitions used for version 09-50 or earlier from jp1hosts to jp1hosts2.

For details about how to specify ANY binding addresses and how to configure jp1hosts2, see the JP1/Base User's Guide.

(b) JP1/AJS3 settings for communication using IPv6 addresses

The following describes the settings required by JP1/AJS3 - Manager and JP1/AJS3 - Agent to enable communication using IPv6 addresses.

Settings for JP1/AJS3 - Manager and JP1/AJS3 - Agent

Using IPv6 addresses in JP1/AJS3 is the equivalent of setting up a multiple-LAN configuration that combines IPv6 networks and IPv4 networks. See 2.3.3 Connecting multiple LANs, and then specify the settings required for operation in a multiple-LAN environment.

Settings for JP1/AJS3 - Manager

No settings are required when you initially install JP1/AJS3 - Manager.

If you perform an upgrade installation of JP1/AJS3 - Manager from version 09-50 or earlier to version 10-00 or later, the embedded database needs to be rebuilt. For details about the setup, see 3.5.3 Settings for communication using IPv6 addresses in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows) or 13.4.6 Settings for communication using IPv6 addresses in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX).

Settings for JP1/AJS3 - Agent

When the version is 10-00 or later, settings are not required regardless of the installation method.

(c) Configuring a firewall for communication using IPv6 addresses

When you use JP1/AJS3 in a network environment with a firewall, configure the firewall so that the IPv6 addresses used by JP1/AJS3 can pass through the firewall.

Note that JP1/AJS3 version 10 or later uses the loopback address. Configure the firewall so that the loopback address in IPv6 format can pass through the firewall.

(6) Cautionary notes on communication using IPv6 addresses

Before you attempt installation or uninstallation, or attempt to enable or disable the IPv4 and IPv6 protocols on running hosts, stop the JP1/AJS3 services.

The OpenView Status Report job cannot be used for communication using IPv6 addresses.

(7) Examples of configurations for environments using IPv6 addresses and their communication settings

For JP1/AJS3 to be able to perform communication using IPv6 addresses, jp1hosts2 must be defined so that the host names of connection target hosts can be resolved to IP addresses.

The following figure shows an example configuration for an environment using IPv6 addresses for communication.

Figure 2‒26: Example of a configuration for an environment using IPv6 addresses

In this system configuration example, jp1hosts2 is defined as follows on each host.

jp1hosts2 on Mng01

Mng01 2001:db8::1e 10.0.0.30
Agt01 10.0.0.10
Agt02 10.0.0.20
Agt03 2001:db8::28
Agt04 2001:db8::32

jp1hosts2 on Agt01

Agt01 10.0.0.10
Mng01 10.0.0.30

jp1hosts2 on Agt02

Agt02 10.0.0.20
Mng01 10.0.0.30

jp1hosts2 on Agt03

Agt03 2001:db8::28
Mng01 2001:db8::1e

jp1hosts2 on Agt04

Agt04 2001:db8::32
Mng01 2001:db8::1e

For details about jp1hosts2, see the JP1/Base User's Guide.

2.3.6 Encryption of JP1/AJS3 communications with SSL

Messages communicated between JP1/AJS3 hosts can be encrypted with SSL. Encrypting messages helps prevent information being intercepted and compromised. Note, however, that some types of communications, such as communications with the destination agents of a flexible job, cannot be encrypted. Use other means to ensure the security of communications.

This subsection gives an overview of SSL and the general procedure for setting up SSL.

(1) Basic terminology for SSL communications

The following table describes basic terminology for SSL communications.

Table 2‒28: Basic terminology for SSL communication

No.

Terms

Description

1

SSL (Secure Sockets Layer)

A protocol for sending and receiving encrypted information over the network.

By implementing certificate authentication and key exchange between a client and a server, you can encrypt communications.

2

TLS (Transport Layer Security)

A protocol that includes improvements to SSL. The protocol name was changed to TLS with SSL 3.0 being the last version named SSL.

In this manual, the term SSL includes TLS.

3

OpenSSL

An SSL library developed and provided as open source that supports SSL or TLS.

4

CA (Certificate Authority)

A certificate authority (CA) that issues certificates required for using SSL.

There are two types of CAs:

Root CA

A root CA self-certifies the validity of itself.

Intermediate CA

An intermediate CA certifies the validity of itself by certification provided by a higher-level CA other than a root CA.

5

CSR (Certificate Signing Request)

A certificate signing request (CSR) required for the issuance of a server certificate. A CSR contains information such as a public key, and the organization name and location of the requester.

A CSR is submitted to a CA, which then signs the CSR and issues a server certificate.

6

Server certificate

Electronic information that certifies the validity of the requester organization of a CSR.

7

Root certificate

A certificate issued by a root CA to certify its own validity. A root certificate is used to verify the validity of the CA that issued a server certificate.

8

Intermediate certificate

A certificate issued by an intermediate CA to certify its own validity. An intermediate certificate in combination with a root certificate certifies the validity of the CA that issued a server certificate.

9

CN (Common Name)

A piece of information registered in a server certificate, which refers to a domain name (host name) of the server to which the server certificate is applied.

10

SAN (Subject Alternative Names)

A piece of information registered in a server certificate, which indicates information that is used as an alternative name for the CN.

Because a SAN can have multiple values, specifying a SAN enables SSL communications with multiple connection destinations by using a single server certificate.

11

Wildcard certificate

A type of server certificate with an asterisk (*) specified in the host name part of a CN or SAN.

This enables SSL communications with different connection destinations with different host names on the same domain by using a single server certificate. The use of a wildcard certificate is allowed for JP1/AJS3 SSL communication.

Note that an asterisk (*) can be used only at the beginning of a CN or SAN (in the host name part). You cannot use an asterisk (*) in any other part. In addition, you cannot use a regular expression such as a* to mean "a host name starting with a".

For example, if a CN is set to *.example.com, such a single server certificate supports multiple host names as follows:

aaa.example.com

bbb.example.com

(2) Overview of JP1/AJS3 SSL communications

The messages communicated between each component of JP1/AJS3 can be encrypted by using SSL communications. This functionality is called the communication encryption function. The communication encryption function can be enabled or disabled for each component. In JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, and JP1/AJS3 - Web Console, the communication encryption function must either be enabled or disabled on both components that communicate with each other. Note that you can specify INETD for the environment setting parameter AJS3SSL to disable the communication encryption function for communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent. In that case, the communications are disabled even if the communication encryption function is enabled for communications between JP1/AJS3 - View and JP1/AJS3 - Manager.

The following describes the communication encryption function for each component.

JP1/AJS3 - Manager

If you enable the communication encryption function in JP1/AJS3 - Manager, communications between another instance of JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, and JP1/AJS3 - Web Console are encrypted.

To enable the communication encryption function in JP1/AJS3 - Manager, you must specify settings in JP1/Base. If the communication encryption function is enabled, messages sent from JP1/AJS3 - Manager are encrypted by OpenSSL on JP1/Base.

For details about JP1/Base SSL communications, see the description of the communication encryption function in the JP1/Base User's Guide.

JP1/AJS3 - Agent

The communication encryption function in JP1/AJS3 - Agent can be used to encrypt communications between JP1/AJS3 - Manager.

To enable the communication encryption function in JP1/AJS3 - Agent, setting must be made in JP1/Base. If the communication encryption function is enabled, messages sent from JP1/AJS3 - Agent are encrypted by OpenSSL on JP1/Base.

For details on JP1/Base SSL communication, see a description on the communication encryption function in the JP1/Base User's Guide.

JP1/AJS3 - View

The communication encryption function in JP1/AJS3 - View can be used to encrypt communications with JP1/AJS3 - Manager.

To enable the communication encryption function in JP1/AJS3 - View, you must edit the file that specifies the names of the hosts that use non-encrypted communications (nosslhost.conf) on JP1/AJS3 - View and enable the communication encryption function.

JP1/AJS3 - Web Console

The communication encryption function in JP1/AJS3 - Web Console can be used to encrypt the following communications:

Communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager

To encrypt communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager, edit the file that specifies the names of the hosts that use non-encrypted communications (nosslhost.conf) on JP1/AJS3 - Web Console and enable the communication encryption function.

Communications between a web browser and JP1/AJS3 - Web Console

To encrypt communication between a web browser and JP1/AJS3 - Web Console, a server certificate and a private key are required.

You must also enable SSL communications on client programs such as Web GUI and user applications using a web browser or other settings.

Note that the following communications are excluded from the JP1/AJS3 communication encryption function. Use other means to ensure the security of communications.

Communications with a destination agent for a flexible job

Communications between JP1/AJS3 - Print Option Manager and JP1/AJS3 - Print Option

Communications between the execution agent of an HTTP connection job and the HTTP connection destination (web-based business system)

Communications between the execution agent of an email sending job for which Outlook is not used and an SMTP or POP3 server

Communications between JP1/AJS3 - Manager and a linked product that does not support the communication encryption function

Examples of other means to ensure the security of communications:

Using VPN

Enabling HTTPS communications in the settings for an HTTP connection job

The following communications are also excluded from the JP1/AJS3 communication encryption function, but are not at risk of interception.

Local host communications within JP1/AJS3 - Manager or JP1/AJS3 - Agent, which uses a port that is not used for communications with other hosts.

The following figure shows the communications that can be covered by the communication encryption function.

Figure 2‒27: Communications covered by the communication encryption function

Cautionary notes

If SSL communications are enabled on one component and disabled on the other component, those components cannot communicate each other. Either enable or disable SSL communication on both components that communicate with each other.

The only encryption protocol supported by the JP1/AJS3 communication encryption function is TLS version 1.2. No other protocol or version is supported.

If you enable the communication encryption function of a JP1/AJS3 product, remember that the product becomes unable to link with versions of JP1/AJS3 products or with other products that do not support the communication encryption function. To link with such products, disable the communication encryption function.

(3) Server certificate and root certificate in manager/agent system configurations

To encrypt a message transferred between a manager host and an agent host with SSL, a server certificate is required for the server-side host, and a root certificate is required for the client-side host.

In manager/agent system configurations, the side that sends a processing request is called a client, and the destination of the request is called a server. In other words, from a manager host's perspective, the local host that sends a job execution request is the client, and the destination agent host is the server. Conversely, from an agent's host perspective, the local host that sends job execution results is the client, and the destination manager host is the server. Therefore, a manager and an agent each require a server certificate and a root certificate.

Because a manager host also communicates with the local host, a root certificate that corresponds to its own server certificate is also required.

The following figure shows how server certificates and root certificates are placed in a manager/agent system configuration.

Figure 2‒28: Placement of server certificates and root certificates in a manager/agent system configuration

The following describes a combination of certificates to be issued by the same CA. The numbers in the figure correspond to the numbers in the following list.

For the manager host, the agent host is the server and the manager host itself is the client. Therefore, server certificate A is required on the agent host and root certificate A is required on the manager host.

For the agent host, the manager host is the server and the agent host itself is the client. Therefore, root certificate M is required on the agent host and server certificate M is required on the manager host.

The manager host also communicates with the local host, so root certificate M, which corresponds to its own server certificate M, is required. However, if server certificate A and server certificate M are issued by the same CA, root certificate M and root certificate A will be the same. In such a case, it is not necessary to obtain root certificate M separately and place it on the manager host.

For the JP1/AJS3 - View host, the manager host is the server, and the JP1/AJS3 - View host is the client. Therefore, root certificate M, which corresponds to the manager host's server certificate M, is required.

As above, in a manager/agent system configuration, all the manager hosts and agent hosts require server certificates and root certificates, and JP1/AJS3 - View hosts require root certificates.

(4) The general procedure for setting server certificates and root certificates in a manager/agent system configuration

Request issuance of a server certificate and a root certificate to a CA. The following figure shows the general procedure for obtaining and setting the server certificates and root certificates.

Figure 2‒29: The general procedure for obtaining and setting a server certificate and a root certificate

If there are multiple manager hosts and agent hosts, perform this procedure on all combinations of manager hosts and agent hosts that communicate with each other. If there are multiple JP1/AJS3 - View hosts, perform the client host procedure on all the JP1/AJS3 - View hosts.

For details about settings, see 21.4.2 SSL communication setup procedure (in a manager/agent configuration) in the JP1/Automatic Job Management System 3 Configuration Guide.

(5) Server certificates and root certificates on a Web Console server

When a Web Console server is used, communications for the following hosts must be encrypted besides encrypting the communications between the manager hosts, agent hosts, and JP1/AJS3 - View hosts.

Communications between the Web Console server and manager hosts

Communications between a web browser and the Web Console server

How a certificate is obtained and placed on each host depends on whether the Web Console server and the manager host are installed on different hosts or on the same host.

(a) When the Web Console server and the manager host are installed on different hosts

The manager host and the agent host require a server certificate and a root certificate. The server certificate is obtained by using OpenSSL on JP1/Base.

The Web Console server requires a root certificate to verify the server certificate on the manager host. The Web Console server also requires a server certificate to connect with a client such as a web browser using SSL communications. The server certificate is obtained by using JP1/AJS3 - Web Console functionality.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on different hosts.

Figure 2‒30: Placement of server certificates and root certificates when the Web Console server and the manager host are installed on different hosts

The manager host and agent host require a combination of server certificates and root certificates similar to the one in a manager/agent system configuration (1 to 3 in the figure). The Web Console server that communicates with the manager host requires root certificate M to verify the manager host's server certificate M (4 in the figure).

For the Web Console server to communicate with the client host with SSL, the Web Console server requires the server certificate W (5 in the figure).

If the same CA issues the server certificates of the hosts, root certificate A and root certificate M will be the same file. It is not necessary to obtain these certificates separately or place them in the manager host separately.

(b) When the Web Console server and the manager host are installed on the same host

The manager host and the Web Console server share a server certificate. The server certificate is obtained by using either JP1/Base or JP1/AJS3 - Web Console.

Cautionary note

When JP1/AJS3 - Web Console and JP1/AJS3 - Manager are installed on the same server (machine) but on a different host, a server certificate cannot be shared. See (a) When the Web Console server and the manager host are installed on different hosts and obtain a server certificate for each host.

When using JP1/Base to obtain a server certificate

Use JP1/Base OpenSSL to obtain a server certificate and copy it to a folder of JP1/AJS3 - Web Console.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on the same host and JP1/Base is used to obtain a server certificate.

Figure 2‒31: When the Web Console server and the manager host are installed on the same host (using JP1/Base)

The manager host and agent host require a combination of server certificates and root certificates similar to the one in a manager/agent system configuration (1 to 3 in the figure). JP1/AJS3 - Web Console that communicates with the manager host requires the root certificate M to verify the manager host's root certificate M (4 in the figure).

For JP1/AJS3 - Web Console to communicate with a client host with SSL, JP1/AJS3 - Web Console requires a server certificate. Copy the server certificate M in the folder of JP1/AJS3 - Web Console (5 in the figure). For SSL communications with the client host, the copied server certificate M is used (6 in the figure).

If the same CA issues the server certificates of the hosts, root certificate A and root certificate M will be the same file. It is not necessary to obtain these certificates separately or place them in the manager host separately.

When using JP1/AJS3 - Web Console to obtain a server certificate

Use JP1/AJS3 - Web Console functionality to create a CSR. Use the CSR to obtain a server certificate, store the certificate in a folder of JP1/AJS3 - Web Console, and specify the path to the server certificate in the JP1/Base common definition information.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on the same host and JP1/AJS3 - Web Console is used to obtain a server certificate.

Figure 2‒32: When the Web Console server and the manager host are installed on the same host (using JP1/AJS3 - Web Console)

For JP1/AJS3 - Web Console to communicate with a client host with SSL, JP1/AJS3 - Web Console requires a server certificate. Use JP1/AJS3 - Web Console functionality to obtain the server certificate W, and place it in a folder of JP1/AJS3 - Web Console. For SSL communication between JP1/AJS3 - Web Console and the client host, the server certificate W is used (1 in the figure).

Specify the path to server certificate W in the JP1/Base common definition information (2 in the figure). Store root certificate W, which corresponds to server certificate W, in JP1/Base and in the agent host (2 and 3 in the figure). Also store the root certificate W in JP1/AJS3 - Web Console that communicates with the manager host (4 in the figure). As in a manager/agent system configuration, the agent host requires the server certificate A and the manager host (JP1/Base) requires the root certificate A (5 in the figure).

If the same CA issues the server certificates of the hosts, root certificate A and root certificate M will be the same file. It is not necessary to obtain these certificates separately or place them in the manager host separately.

(6) The general procedure for setting a server certificate and a root certificate in an environment that includes a Web Console server

Basically, the general procedure for setting the server certificates and root certificates in an environment that includes a Web Console server is the same as (4) The general procedure for setting server certificates and root certificates in a manager/agent system configuration. However, how a CSR and a private key is created and how and where the obtained server certificate is placed depends on the system configuration of the Web Console server and manager host.

For details, see 21.4.1 JP1/AJS3 system configuration and SSL communication setup procedure in the JP1/Automatic Job Management System 3 Configuration Guide.

(7) Cautionary notes on SSL communications

The following provides cautionary notes on SSL communications.

(a) Cautionary notes on certificates

If verification of a server certificate fails, the communications processing stops causing an error.

A server certificate or a root certificate has an expiration date. Manage the certificates in the proper method and complete the replacement procedure before they expire. The expiration of a certificate is judged by the system time. It is not related to a local date and time of the scheduler service. The following shows the communications behavior if the certificate has expired:

For the communication between JP1/AJS3 - Manager and JP1/AJS3 - Agent, encryption is performed even if the certificate has expired. No job executions fail. However, a warning message is output once per day. This warning message is not output for queueless jobs.

For the communication between JP1/AJS3 - View and JP1/AJS3 - Manager, if the certificate has expired, you cannot log in from JP1/AJS3 - View to JP1/AJS3 - Manager.

For the communication between JP1/AJS3 - Web Console and JP1/AJS3 - Manager, if the certificate has expired, you cannot log in from the Web GUI to JP1/AJS3 - Manager. However, for the communication between the web browser and JP1/AJS3 - Web Console, the Web GUI can be displayed in the web browser even if the certificate has expired.

(b) Cautionary notes on setting a CN and SAN

The following provides cautionary notes on setting a CN or SAN.

The JP1/AJS3 communication encryption function checks both CN and SAN to prevent server spoofing. However, CN and SAN are not checked for communications in a single host. In addition, the CN is not checked if a SAN is specified. Therefore, specify the same value for the SAN and CN if a SAN is specified.

Specify a host name for the CN or SAN. Do not specify an IP address.

If a wildcard certificate is used, an asterisk (*) can be used only at the beginning of the CN or SAN (host name part). You cannot use an asterisk (*) in any other part. In addition, you cannot use a regular expression such as a* to mean "a host name starting with a". For example, *.example.com can be set as CN or SAN, but a*.example.com or test.*.com cannot.

If you use an alias host name to specify a host, specify the name as the SAN.

If you use a short name for a host name, specify both the short name and the FQDN as the SAN. If you do not specify both names, job execution might end in error.

If host is specified for the environment setting parameter ResolveAgentInfo, when the manager host communicates with the agent host, it communicates with the real host as well as the execution target host saved as the execution agent information. Therefore, also specify the real host name of the agent host in the SAN.

If you perform a definition pre-check or queueless job in a logical host environment, specify the physical host name and all the logical host names on the physical host for the SAN in the server certificate on the physical host.

The definition pre-check function and a queueless job service are processed by a process on a physical host. If the process is requested from a logical host, the server certificate of the physical host is sent to the client. This is why the physical host name and logical host name must be specified for the SAN in the server certificate on the physical host.

(c) Cautionary notes when the SSL enabled/disabled state differs between the physical host and the logical host

The following provides cautionary notes when the SSL enabled/disabled state differs between the physical host and the logical host.

If the manager host or authentication server is installed as a logical host

The SSL communication enabled/disabled status of the manager host and authentication server must match between both hosts. If the SSL communication enabled/disabled status does not match between the manager host and the authentication server, you cannot log in to JP1/AJS3 - Manager from JP1/AJS3 - View or Web GUI.

The following describes an example when the manager host or authentication server is installed as a logical host.

Figure 2‒33: Example when the manager host or authentication server is installed as a logical host

This figure assumes that JP1/AJS3 - Manager and JP1/Base is installed on all the physical hosts and logical hosts.

Because SSL communications are enabled on hostA, hostB can be set as the authentication server for hostA. hostA-L and hostB-L, on which SSL communications are disabled, cannot be set as the authentication server.

On the other hand, because SSL communications are disabled on hostA-L, hostB-L can be set as the authentication server for hostA-L. hostA and hostB, on which SSL communications are disabled, cannot be set as the authentication server.

If the definition pre-check function is used

If the definition pre-check function is used, SSL communications are enabled or disabled as per the settings on the physical host. Therefore, the SSL communication enabled/disabled status must match on the physical hosts for the pre-check requester host and execution destination host.

The following describes an example when the definition pre-check function is used.

Figure 2‒34: Example when the definition pre-check function is used

In this figure, the hostA or hostC is a pre-check requester host, and hostB or hostD is a pre-check execution destination host.

The SSL communication settings for the physical hosts, hostA and hostB, are the same. Therefore, for example, when hostA-L requests a pre-check to hostB, the pre-check function performs successfully even though the SSL communication for the requester host does not match. Similarly, when hostA requests a pre-check to hostA-L, the pre-check function performs successfully.

On the other hand, the SSL communication settings for the physical host, hostC and hostD, are not the same. Therefore, for example, when hostC-L requests a pre-check to hostD, the pre-check function ends in error even though the SSL communication setting for the requester host matches.

If a queueless job is executed

If a queueless job is executed, SSL communications are enabled or disabled on the queueless job execution requester as specified on both the logical host and the physical host. On the other hand, the SSL communication settings on the execution destination queueless agent follows the settings on the physical host regardless of whether it is a logical host or physical host. If the SSL communication settings differ between the execution requester and the execution destination, a queueless job cannot perform successfully. Specify the same SSL communication enabled/disabled status for the execution requester and the execution destination.

The following describes an example when a queueless job can be executed.

Figure 2‒35: Example when a queueless job can be executed

In this figure, the queueless job execution requester is a physical host, hostA. SSL communication on the execution requester is enabled, in accordance to hostA. At this time, the queueless job execution destination has the same SSL communication setting with the execution requester. The queueless job execution destination can be any of hostA (local host), hostA-L, hostB, or hostB-L because SSL communications are enabled on their physical hosts (hostA and hostB). Therefore, a queueless job can be executed.

On the other hand, the following figure shows an example when a queueless job cannot be executed.

Figure 2‒36: Example when a queueless job cannot be executed

In this figure, the queueless job execution requester is a logical host, hostA-L. SSL communication on the execution requester is disabled, in accordance with hostA-L. However, whether the queueless job execution destination is any of hostA (local host), hostA-L, hostB, or hostB-L, SSL communication settings differ between the execution requester and the execution destination. This is because SSL communications are enabled on their physical hosts (hostA and hostB). Therefore, a queueless job continues to be in a wait status and is not executed. If you want to end a queueless job in a wait status, change the status of the queueless job.

2.3.7 Communications used in a WAN

When using a WAN with JP1/AJS3, make sure you use them in a communications environment with secure communications and stable communication lines.

You can ensure secure communications in a communications environment by, for example, using a VPN.

If a communication line is unstable, job delays or errors whose causes are hard to identify might occur. To prevent such problems, use a communication line that has a stable data transfer rate.

We do not recommend using a network for which you are charged based on the amount of time or amount of data.

If you do use a WAN environment for which you are charged based on the amount of time or amount of data, you can reduce communication costs by, for example, disabling KeepAlive (which requires a continuous connection that checks connectivity with the destination) in the environment settings. Setting devices such as routers to disconnect automatically when inactivity is detected will also reduce costs.

2.3.8 Operation in a DNS environment

You can use JP1/AJS in a DNS environment. To use JP1/AJS in a manager/agent configuration, define normal lookup on the DNS.

The following figure shows the settings required for name resolution by using normal lookup for JP1/AJS3 products.

Figure 2‒37: Settings required for name resolution by using normal lookup for JP1/AJS3 products

If you want to use a FQDN (Fully Qualified Domain Name) host name as the execution agent name for event jobs, you need to specify the settings described in this subsection. You do not need to specify these settings when using event jobs if there are no duplicated host names in the same network, in an environment that spans multiple domains, or if you do not plan to use event jobs.

When the settings described in this section are specified, each host obtains an FQDN host name from the local host name and sends it to the other hosts during communication between the manager and agent hosts when event jobs are executed. This allows the manager and agent hosts to uniquely identify each other and to correctly process the communication data.

You do not need to switch to using FQDN hosts names if all the host names in the same network are unique and no problems occur.

(1) When to switch to using FQDN host names for event jobs

You do not need to change the current settings if the event jobs use the DNS and host names that are unique in the same network. Follow the flowchart below to determine whether you need to switch to using FQDN host names for event jobs.

Figure 2‒38: Judging the necessity of switching to operation with host names in the FQDN format

New settings are required if the flowchart above indicates that you need to switch to using FQDN host names. For the setting procedure, see 6.3.5 Using fully qualified domain names (FQDN) when using event jobs during DNS operation in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.5 Using fully qualified domain names (FQDN) when using event jobs during DNS operation in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

Note that, by default, Receive JP1 Event jobs, Monitoring log files jobs, and Monitoring event log jobs obtain the host name of the host on which they are executed. These jobs then operate using the JP1/Base event server that has the same name as the host name they obtained. Therefore, to execute these jobs on an agent host that performs operations with the event server by using the FQDN event server name, set the FQDN agent host name or FQDN event server name used by JP1/AJS3 on the agent host. For details about how to set the names, see 6.3.17 Setting the event server name in the system using DNS in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.16 Setting the event server name in the system using DNS in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

If necessary, see 6.8.1 Canceling and re-setting service dependencies in the JP1/Automatic Job Management System 3 Configuration Guide and then set the JP1/AJS3 service dependencies.

(2) Example of using FQDN host names when the DNS is used

This subsection shows an example of using FQDN host names to execute a job for agent hosts that have the same host name HostA, but have different IP addresses (100.0.0.200 and 200.0.0.200). In this example, the job has been assigned the execution host names HostA.hitachi_1.co.jp and HostA.hitachi_2.co.jp, and is entered from the manager host with host name HostM and IP address 100.0.0.100.

The example assumes that the hostname command executed on a manager host or agent host will return a host name in FQDN format. For details about the required setting when changing to FQDN host names, see (1) When to switch to using FQDN host names for event jobs above.

Figure 2‒39: Example of operation with FQDN host names

For this example, set the hosts files on the manager and the agent hosts in the local domain as follows (see (1) in the figure).

Note that the settings take effect in UNIX.

The hosts file at the manager:

Specify the following setting so that the name HostA can be resolved:

100.0.0.200 HostA.hitachi_1.co.jp

The hosts files at the agent (HostA on Hitachi_1.co.jp):

Specify the following setting so that the name HostM can be resolved:

100.0.0.100 HostM.hitachi_1.co.jp

In an environment in which neither of the DNS servers is able to resolve the host name of the other server, set the hosts files for both the manager and agent hosts as follows (see (2) in the figure).

The hosts file of the manager server on hitachi_1.co.jp:

200.0.0.200 HostA.hitachi_2.cojp

The hosts file of the agent server on hitachi_2.co.jp:

100.0.0.100 HostM.hitachi_1.co.jp

When you specify the above settings, manager host name HostM.hitachi_1.co.jp is sent to each agent host when the job is executed, and the agent hosts send a reply to HostM.hitachi_1.co.jp.

Cautionary notes

Use the manager host in an environment in which it can resolve the name of each agent host in FQDN format. Use the agents in an environment in which they can resolve the manager's name in FQDN format.

For host name resolution in a UNIX environment, the DNS must be searched before the hosts file. Otherwise, correct FQDN host names might not be acquired.

If you switch to FQDN host names, host names in FQDN format are used for the communication between manager hosts and agent hosts when event jobs are executed. If short local host names are defined in the jp1hosts information or jp1hosts2 information, the settings in the jp1hosts information or jp1hosts2 information take precedence over the DNS server. In that case, short host names are used for communication between manager hosts and agent hosts when event jobs are executed. If you define a short local host name in the jp1hosts information or jp1hosts2 information on an agent host, define the short agent host name in the jp1hosts information or jp1hosts2 information on the manager host. If you define a short local host name in the jp1hosts information or jp1hosts2 information on the manager host, define the short manager host name in the jp1hosts information or jp1hosts2 information on the agent hosts. For details about how to define jp1hosts information or jp1hosts2 information, see the JP1/Base User's Guide.

As long as the manager and agents operate within the same domain (hitachi_1.co.jp), it does not matter whether the value of DNSEstablish is Y or N. However, the manager host and agent hosts must operate in an environment in which the manager host and each agent host can resolve the name of the other hosts.

(3) Notes on operation in a DNS environment

Note the following when using JP1/AJS3 in a DNS environment:

In a DNS environment, FQDN host names cannot be used for logical host names. Therefore, specify the settings so that IP addresses can be resolved from logical host names that are not in FQDN format. If you are considering using a cluster configuration for a system consisting of multiple domains, specify unique logical host names.

Run JP1/AJS3 in an environment in which the host names of agent hosts can be resolved as follows.

When you specify Y for the environment setting parameter DNSEstablish, the host names of agent hosts are in the FQDN format.

If you do not use DNS or you specify N for the environment setting parameter DNSEstablish, the host names of agent hosts are the ones that are output when you execute the hostname command.

When you set an alias host name as the execution agent for event jobs, make sure that the execution host name from which the alias has been defined can also be resolved on the manager host.

If a job has already been registered and the IP address cannot be resolved, job retry processing is performed. For details about this processing, see Table 2-3 Job retry process if a network error occurs in 2.2.2(4) Notes on manager/agent system configurations.

When you execute jobs on multiple hosts, specify settings that allow for the resolution of the IP addresses for the manager hosts, agent hosts, and the hosts in other systems.

When you obtain FQDN host names in an environment that uses the DNS, the case (upper or lower) of alphabetic characters in the host name might change each time it is obtained. The JP1/AJS manager used in such an environment is handled as another manager because the manager host name viewed from the agent has changed. This situation can lead to the following problems when an event job is executed.

When the JP1/AJS3 service on the manager is restarted while a jobnet with a start condition is running, any monitored event that was detected after the restart is detected again.

When the option to continue execution of active event jobs is enabled, if the JP1/AJS3 service on the manager is restarted in hot-start mode while an event job is running, multiple events are incorrectly detected as one event.

To prevent such problems, before you start operating JP1/AJS3 in a DNS environment, set a fixed manager name that will be used for communication between the manager and agent hosts. For details, see 6.3.15 Settings for ensuring that a fixed manager host name is used when event jobs are executed in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.15 Settings for ensuring that a fixed manager host name is used when event jobs are executed in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX). However, a fixed manager name is not necessary if you execute the jpoagoec command on the agent host on which event jobs are executed and the manager host names remembered by the agent are unique regardless of case.

To switch to operation that uses FQDN host names, use the procedure in 7.9.5 Changing to FQDN host names for event jobs in a DNS environment in the JP1/Automatic Job Management System 3 Administration Guide.

If you have switched to operation using FQDN host names, use the jp1ping command to make sure that the manager host is able to resolve agent host names and that the agent hosts are able to resolve the manager host name. For details about the jp1ping command, see the JP1/Base User's Guide.

2.3.9 Restricting hosts that can access JP1/AJS3

Connection source restriction refers to functionality that limits the hosts that are able to access JP1/AJS3. Restricting access to JP1/AJS3 - Manager or JP1/AJS3 - Agent can prevent unintended hosts from performing operations or executing jobs.

To use the connection source restriction function, specify a value for the environment setting parameter CONNECTIONRESTRICTION, and create a connection permission configuration file for each manager host or agent host (logical host in the case of a logical host). If you specify the IP addresses of hosts for which access is to be permitted, then only the hosts that have one of the specified IP addresses are given access. An access attempt by any other host will be rejected. For details about the environment setting parameter CONNECTIONRESTRICTION, see 20.11.2(5) CONNECTIONRESTRICTION in the JP1/Automatic Job Management System 3 Configuration Guide.

There are two connection permission configuration files: a manager connection permission configuration file (permitted_host_manager.conf) and an agent connection permission configuration file (permitted_host_agent.conf).

For details about how to restrict access to JP1/AJS3, see 21.2 Restricting connections to JP1/AJS3 in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

If there is no connection permission configuration file that corresponds to the value of the environment setting parameter CONNECTIONRESTRICTION in the environment setting file storage folder, the JP1/AJS3 service or the JP1/AJS3 Queueless Agent service terminates abnormally.

(1) Operations subject to access restrictions

The connection source restriction function can prohibit the following operations from accessing JP1/AJS3:

Log in to JP1/AJS3 - Manager from JP1/AJS3 - View

Executions of various types of units

Connections from Web Console server

Connections from related products

Remote executions of commands that start with ajs

Remote executions of commands that start with jpq

Each of these cases are described below.

(a) Logging in to JP1/AJS3 - Manager from JP1/AJS3 - View

You can limit the JP1/AJS3 - View hosts that are able to log in to JP1/AJS3 - Manager.

To do so, specify the IP addresses whose connection you want to permit in the manager connection permission configuration file.

If you change the settings to deny access by specifying the IP address of a JP1/AJS3 - View host after the host has already connected to JP1/AJS3 - Manager, operations such as execution registration and kill can be performed from the already connected JP1/AJS3 - View. Restrictions of the JP1/AJS3 - View connection take effect only at the next login.

(b) Restricting executions of various types of units

You can prohibit unintended hosts from executing various types of units.

When JP1/AJS3 - Manager requests that JP1/AJS3 - Agent execute, re-execute, kill, or check the status of jobs, JP1/AJS3 - Agent checks whether the IP address of the requester host is set in the agent connection permission configuration file.

For a unit such as a remote jobnet that connects to another manager host, the destination JP1/AJS3 - Manager checks whether the IP address of the requester host is set in the manager connection permission configuration file.

The request will be rejected if the IP address is not found in the connection permission configuration file.

The following table shows which connection permission configuration file is used to restrict access for each unit type.

Table 2‒29: Files used to restrict connection source restriction by unit

No

Unit type

Files used for connection source restriction

1

Remote jobnet

M

2

Manager job group

M

3

Manager jobnet

M

4

Planning group

--

5

Start condition

--

6

Standard job

Unix job

A

7

PC job

A

8

QUEUE job

M, A#1

9

Flexible job

A#2

10

Jobnet connector

--

11

OR job

--

12

Judgment job

--

13

Event job

A

14

Action job

A

15

Custom job

A

16

Passing information settings job

--

17

HTTP connection job

A

Legend:

M: Manager connection permission configuration file

A: Agent connection permission configuration file

--: Connection source restriction is not possible.

#1

When a QUEUE job is registered in the queue, the manager connection permission configuration file on the manager host that owns the queue determines whether the connection (registration) is permitted.

When a QUEUE job is executed, the agent connection permission configuration file on the agent host that is connected to the queue determines whether the connection (job execution) is permitted.

#2

A connection from a manager host to a relay agent is a target of the connection source restriction function, but a connection from a manager host or a relay agent to a destination agent is excluded.

For details about flexible jobs, see 2.9 Executing jobs in a cloud environment.

(c) Restricting connections from Web Console server

Connection from JP1/AJS3 - Web Console to JP1/AJS3 - Manager can be restricted.

Specify the IP address of the Web Console server whose connection you want to permit in the connection permission configuration file.

(d) Restricting connections from related products

You can prohibit related products from accessing JP1/AJS3 - Manager.

In the connection permission configuration file, specify the IP addresses of those hosts to which you want to permit connections and on which related products are installed.

You can restrict access to JP1/AJS3 - Manager from the following products:

JP1/AJS3 - Definition Assistant

JP1/NQSEXEC (for receiving job execution requests)

(e) Restricting remote executions of commands that start with ajs

You can restrict connections to JP1/AJS3 - Manager to be used for remote executions of commands that start with ajs.

If you remotely execute commands that start with ajs, specify the IP address of the manager host initiating command execution in the manager connection permission configuration file on the manager host where the commands are to be executed.

For details about commands that can be executed remotely, see 1.1.7 Remote execution of a command in the JP1/Automatic Job Management System 3 Command Reference.

(f) Restricting remote executions of commands that start with jpq

You can restrict connections to JP1/AJS3 - Manager to be used for remote executions of commands that start with jpq.

When you remotely execute commands that start with jpq, specify the IP address of the manager host initiating command execution in the manager connection permission configuration file on the manager host where the commands are to be executed.

(2) Setting the connection permission configuration file

In the connection permission configuration file, specify the IP addresses of the hosts whose connection to JP1/AJS3 - Manager or JP1/AJS3 - Agent you want to permit. Also make sure that the IP address of the local host is specified in the connection permission configuration file when you enable the connection source restriction function in JP1/AJS3 - Manager.

For details about the connection permission configuration file, see 21.2 Restricting connections to JP1/AJS3 in the JP1/Automatic Job Management System 3 Configuration Guide.

Note that caution is necessary if you set IP addresses for the following cases:

If remote jobnets are executed

If the ajschkdef command is used to check the jobnet connector

In a NAT environment

In an environment that uses the ANY binding communication method and uses multiple NICs or alias IP addresses

The following describes the IP addresses you need to specify for each case:

(a) If remote jobnets are executed

If remote jobnets are executed, the IP addresses of the transferring host and the destination host must be set in the connection permission configuration files on both hosts.

The following figure shows an example of executing a remote jobnet in an environment in which connection source restriction is enabled.

Figure 2‒40: Example configuration when a remote jobnet is executed

In this example, the transferring host, the destination host, and the execution host are as follows:

Transfer source host

Local IP address (192.168.31.1)

IP address of the destination host (192.168.31.2)

Transfer destination host

Local IP address (192.168.31.2)

IP address of the transferring host (192.168.31.1)

Execution host

IP address of the destination host (192.168.31.2)

Note

Do not change the connection-source restriction settings on a host while execution of a remote jobnet is being registered. If the connection source restriction function prohibits a connection after the remote jobnet is executed, operations such as status notification, kill, and deletion of the execution host cannot be performed.

(b) If the ajschkdef command is used to check the jobnet connector

If you use the ajschkdef command with the -M option specified to perform a definition pre-check and if a jobnet connector whose Connection range is set to Other service is included as an object to be checked, you need to specify the IP address of the host on which the jobnet connector is defined in the manager connection permission configuration file on the destination host.

The following figure shows an example jobnet connector.

Figure 2‒41: Example jobnet connector

In this example, the IP address of HostA, which is the host on which the jobnet connector is defined, is specified in the manager connection permission configuration file on the destination host HostB. If you execute the ajschkdef command without this specification, the "number of checked units" displayed for NUMBER OF CHECKUNITS in the check results is decreased by the number of units for which connection was denied, and the message KAVS3431-I is output to the integrated trace logs.

For details about ajschkdef command, see ajschkdef in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(c) In a NAT environment

In a NAT environment, the IP address of the host and the IP address used as the communication source differ. Specify the IP address after network address translation (NAT).

The following figure shows an example of restricting access in a NAT environment.

Figure 2‒42: Example of restricting accesses in a NAT environment

In this example, 200.200.200.200 is specified in the agent connection permission configuration file.

(d) In an environment that uses the ANY binding communication method and uses multiple NICs or alias IP addresses

Specify all the addresses that can become actual communication sources.

The following figure shows an example of restricting access in a multiple-NIC environment.

Figure 2‒43: Example of restricting access in a multiple-NIC environment

In this example, 192.168.31.1, 192.168.31.2, and 192.168.31.3, which can be used by the manager host as the source IP addresses, are specified in the agent connection permission configuration file.

2.4 Determining the system environment settings

This section describes matters you need to consider in regard to the system environment settings.

2.4.1 Time zones

This section describes system time zones.

(1) Logging in to JP1/AJS3 - Manager from JP1/AJS3 - View

When you use JP1/AJS3 - View to log in to JP1/AJS3 - Manager, and you check the jobnet execution statuses and execution results, the time displayed obeys the time zone set in the OS of the computer where JP1/AJS3 - View is installed.

In Windows:

When running JP1/AJS3 - Manager in Windows, you cannot set time zones for individual processes (a manager host cannot handle more than one time zone). If your system operates across time zones, set up manager hosts and JP1/AJS3 - View hosts separately for each time zone.

In UNIX:

UNIX allows you to set time zones in process units, so you can set a TZ environment setting variable for each registered user to execute jobnets registered for execution at JP1/AJS3 - Manager (you can use multiple time zones at a single manager host).

However, the following restrictions apply to operations on units:

When working from JP1/AJS3 - View, since you can only handle one time zone, prepare unit definitions for each time zone and start JP1/AJS3 - View separately for each of these time zones.

When you register jobs for execution, use the ajsentry command in an environment where a TZ environment variable is set for each time zone.

Only relative specifications can be made for times (e.g. time changes).

If you want to use a command to check the jobs registered for execution, use the ajsshow command in the environment with the same TZ environment variable that was used when the jobs were registered for execution.

When JP1/AJS3 - View is set up to display Japanese time for execution statuses and execution results, even if the jobnet is actually executed in another country, the time displayed will be Japan time, not the local time in that country. In Windows, to check jobnet execution statuses and execution results from a region with a different time zone in the local time, you have to prepare a computer set to the local time and running JP1/AJS3 - View. For example, to display the execution statuses from New York in New York time, prepare a JP1/AJS3 - View computer with its clock set to New York time.

The following figure shows a system configuration that allows you to check execution statuses on multiple hosts for administrative tasks in different time zones.

Figure 2‒44: Example of a system configuration for checking jobnet execution status on manager hosts in different time zones

See the following cautionary notes when manager hosts and agent hosts operate in different time zones.

These cautionary notes apply when a scheduled job is executed, not when defining a jobnet execution schedule.

Jobnets are scheduled for execution based on the manager's time zone setting.

Cautionary notes

Jobs are executed based on the agent's time zone setting. Times logged in the standard output file and standard error output file are based on the agent's time zone setting.

The job timeout period is governed by the elapsed time, and does not conform to the time zone.

Time data included in the event job passing information (EVDATE, EVTIME, FLCTIME, and MLRCVTIME) has the time zone of the agent host on which the event occurred. When a JP1 event reception monitoring job detects a JP1 event that has been transferred from another host, the time data included in the passing information (EVDATE and EVTIME) is expressed in the time zone of the transfer source. It is not expressed in the manager host's time zone or in the time zone used for other jobs that use the passing information.

When Set next power-on time is set to Change next power-on time for the remote power control job, the next specified power-on time operates according to the time specified in the time zone of the execution user on the host that is executing the job.

The time set in the Valid range of start condition operates according to the time zone on the manager host.

(2) If the Web Console server is used

If the date/time information or execution agent information about a unit is displayed from the Web GUI or a user application, the time is displayed according to the time zone of the manager host. If time zones of the Web Console server and the manager host differ, specify the time zone of the manager host in the environment-settings file (ajs3web.conf) of the Web Console server.

For details about the time zone of the Web Console server, see 4.6.1(2) Time zone of the Web Console server.

2.4.2 Language type and character encoding of the system

This subsection describes the language type and character encoding used in JP1/AJS3.

(1) Available language types

You can use Japanese, English, or Chinese in JP1/AJS3. The language should be used according to intended usage.

(2) Values that can be specified in the LANG environment variable

In UNIX, to set the systems language environment, use the LANG environment variable. The table below lists the values that can be specified in the LANG environment variable. Use this table to select a value. If you do not use a value listed in this table, C (English) will be set. Operation is not guaranteed if the values specified in this table are not specified.

For details about operation using a language other than Japanese, English, or Chinese, see (11) About the operations in multiple language environments.

In Windows, the system language environment cannot be changed.

Table 2‒30: Values that can be specified in the LANG environment variable

OS

Language and character encoding

Value of LANG environment variable

HP-UX

Japanese

Shift-JIS

ja_JP.SJIS

japanese

EUC

ja_JP.eucJP

japanese.euc

UTF-8

ja_JP.utf8

English

ASCII

C

Chinese

GB18030

zh_CN.gb18030

UTF-8

Cannot be used.

Solaris

Japanese

Shift-JIS

ja_JP.PCK

EUC

ja

ja_JP.eucJP

UTF-8

ja_JP.UTF-8

English

ASCII

C

Chinese

GB18030

zh_CN.GB18030

UTF-8

Cannot be used.

AIX

Japanese

Shift-JIS

Ja_JP

Ja_JP.IBM-932

EUC

ja_JP

ja_JP.IBM-eucJP

UTF-8

JA_JP

JA_JP.UTF-8

English

ASCII

C

Chinese

GB18030

Zh_CN.GB18030

UTF-8

Cannot be used.

Linux

Japanese

Shift-JIS

ja_JP.SJIS#

ja_JP.sjis#

EUC

Cannot be used.

UTF-8

ja_JP.UTF-8

ja_JP.utf8

English

ASCII

C

Chinese

GB18030

zh_CN.gb18030

UTF-8

Cannot be used.

#

Can only be used in SUSE Linux.

Cautionary note

The character encoding used in JP1/AJS3 must be the same as the one used in JP1/Base. There might be some cases in which a character encoding usable in JP1/Base cannot be used in JP1/AJS3.

(3) Whether language settings can be mixed in the same device

If JP1/AJS3 is used on a logical host, whether hosts with mixed language types can exist or not depends on the host OS.

In Windows:

Hosts with different language types cannot exist on the same device. All the logical hosts and physical hosts must have the same language type.

In UNIX:

If the language types of all the hosts on the same device are Japanese or English, hosts with different language types can exist. Therefore, the language type can be either Japanese or English for each logical host.

However, hosts whose language settings are set to Chinese, Korean, German, French, Spanish or Russian cannot exist on the same device as another host that has a different language setting. The language type on all the logical hosts and physical hosts must be the same.

The following figure shows an example in which mixed language types exist on the same device.

Figure 2‒45: Example of mixed language types on the same device

In JP1/AJS3 - Manager, the character encoding of the host must match the character encoding of the scheduler service. The host and scheduler service cannot have different character encodings.

The following figure shows an example of mixed character encodings on the host and the scheduler service.

Figure 2‒46: Example of mixed character encodings on the host and the scheduler service

(4) Whether language settings can be mixed within a system

The following table shows whether a combination of language settings is allowed when hosts with different language types are combined in JP1/AJS3.

Table 2‒31: Whether combinations are allowed when different language types are combined in JP1/AJS3

JP1/AJS - Agent, JP1/AJS - View, or JP1/AJS - Web Console

Japanese

English

Chinese

JP1/AJS - Manager

Japanese

Yes

(Yes)2

(Yes)2

English

(Yes)2

Yes

(Yes)2

Chinese

(Yes)2

(Yes)2

(Yes)1

Legend:

Yes: Supported. If the language type is Japanese, hosts with a different character encoding can exist.

(Yes)1: Supported. The character encoding must be unified to the Chinese character encoding.

(Yes)2: Supported only when all the characters and information are unified to alphanumeric characters (ASCII).

Cautionary note

The combinations (Yes)2 in Table 2-31 are environments of hosts with different language types. In this case, set alphanumeric characters (ASCII) for all texts and information including the unit name, file name, characters used in files, messages in jobs being executed, monitoring conditions for event jobs, and inherited information. If a character other than ASCII is used, the following conditions might occur:

Characters are garbled.

A standard job and HTTP connection job are placed in the Ended abnormally status or operate incorrectly.

An event job is placed in the Ended abnormally status, cannot be detected, or is detected incorrectly.

A process terminates abnormally.

(5) Overview of steps to set the language type and character encoding

This subsection gives an overview of the steps to set the language type and character encoding.

(a) If JP1/AJS3 is installed in a new installation

If JP1/AJS3 - Manager, JP1/AJS3 - Agent, or JP1/AJS3 - View is newly installed, the language type is automatically decided during the installation.

In Windows:

The required language setting is automatically set according to the language type of the OS.

In UNIX:

The required language setting is automatically set according to the LANG environment variable when Hitachi Program Product Installer is started. If necessary, specify the LANG environment variable before starting Hitachi Program Product Installer.

Cautionary note

If you cannot define a job that includes a multi-byte character of the specified language or such a job cannot be executed properly, the LANG environment variable specified during the installation might have been wrong. See 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide and change the language setting.

(b) If JP1/AJS3 is installed in an overwrite installation or upgrade installation

If you install JP1/AJS3 in an overwrite installation or upgrade installation, the language setting before the installation is inherited.

(c) When a logical host is used

Specify the language setting on a logical host after setting up the logical host by using the jajs_setup_cluster command. For details about the jajs_setup_cluster command, see jajs_setup_cluster in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

The following shows the language setting required for setting up a logical host:

In JP1/AJS3 - Manager for Windows:

The language setting of the logical host is inherited from the physical host by the jajs_setup_cluster command. Because hosts with different language types cannot exist in Windows, do not change the language setting on the logical host.

In JP1/AJS3 - Manager for UNIX:

The language setting of the logical host is inherited from the physical host by the jajs_setup_cluster command.

If you operate a logical host with a language type different from the one used on the physical host, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide. Referring to the guide, execute the jajs_setup_cluster command, and then change the language setting on the logical host and the scheduler service.

Cautionary note

The -E option for the jajs_setup_cluster command can only be specified when the character encoding of the logical host is UTF-8. The -E option enables you to specify the same number of characters for names including the unit names between the Shift-JIS environment and the UTF-8 environment. When the -E option is specified, the character encoding of the scheduler database is set to UTF-8, so the character encoding of the logical host must be set to UTF-8.

In JP1/AJS3 - Agent:

The language setting is inherited from the physical host. If you operate a logical host with a language type different from the one used on the physical host, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide. Referring to the guide, change the language setting on the logical host after executing the jajs_setup_cluster command.

(d) When a scheduler service is added (JP1/AJS3 - Manager only)

If you execute the jajs_setup command to add a scheduler service, the character encoding for the added scheduler service (the value of the AJSCHARCODE environment setting parameter) must match the character encoding on the logical host.

The following table lists the default character encoding of the scheduler service added by the jajs_setup command, and the value of the AJSCHARCODE environment setting parameter.

Table 2‒32: Language setting when a scheduler service is newly added

OS

Default character encoding of the scheduler service

The value of the AJSCHARCODE environment setting parameter

Windows

Shift-JIS

SJIS

HP-UX

Shift-JIS

SJIS

Solaris

EUC

EUC

AIX

Shift-JIS

SJIS

Linux

UTF-8

UTF-8

For details about how to change the character encoding, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide.

Cautionary note

The -E option for the jajs_setup command, which enables you to specify the same number of characters for names including the unit names between the Shift-JIS environment and the UTF-8 environment, can only be specified when the character encoding of the logical host is UTF-8. When the -E option is specified, the character encoding of the scheduler database is set to UTF-8, so the character encoding of the logical host must be set to UTF-8.

(6) Locations of the character encoding setting (UNIX only)

When you specify a character encoding in JP1/AJS3 - Manager or JP1/AJS3 - Agent, you must set the same character encoding for the definition files, environment variables, and environment setting parameters listed in the table below. For details about how to specify the character encoding, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide.

Table 2‒33: Locations of the character encoding setting (JP1/AJS3 - Manager or JP1/AJS3 - Agent)

Settings (definition files, environment variables, and environment setting parameters)

What the change affects

Related products

The LANG environment variable applied when the JP1/AJS3 service starts

The character encoding of messages output from the JP1/AJS3 service.

M, A

JP1/AJS3 environment definition file

For a physical host:

/etc/opt/jp1ajs2/conf/jp1ajs_env.conf

For a logical host:

The LANG environment variable in: shared-directory/jp1ajs2/conf/jp1ajs_env.conf

Value of the LANG environment variable to be applied when the JP1/AJS3 service starts.

The character encoding of the information to be output to integrated trace logs and internal logs by schedule control, event/action control, and job execution control.

When the user profile does not contain the LANG environment variable, the default for LANG during job execution.

M, A

JP1/Base parameter definition file

For a physical host:

/etc/opt/jp1base/conf/jp1bs_param.conf

For a logical host:

shared-directory/jp1base/conf/jp1bs_param.conf

The character encoding of the data to be exchanged between the JP1/AJS3 manager host and agent host when standard jobs, HTTP connection jobs, event jobs, action jobs, and custom jobs are executed.

The character encoding set of the data to be exchanged between the jobnet connector and the connected jobnet when the jobnet connector is used to control the execution order of root jobnets.

M, A

AJSCHARCODE parameter in the scheduler service environment definition

The character encoding of the information that will be stored in the scheduler database.

M

SYSLOGCODE #1parameter in the scheduler service environment definition

The character encoding of messages output by the scheduler services to SYSLOG.

The value of the LANG environment variable used at the start of the service when a value other than C (English) is specified.

M

The LANG environment variable#3 when a command#2 for unit operation is executed

The values stored in the scheduler database by the command that operates on the unit.

The log data and character encoding of messages that are output by the command that operates on the unit.

M

The LANG environment variable when a command#5 used to operate execution agents

The values stored in the agent management database.

M

The AJSI18N environment setting parameter in the JP1/AJS3 shared information

The entire JP1/AJS3

M, A

The LANG environment variable when the queueless agent service is started

The character encoding of the messages output by the queueless agent service.

M, A

The AJSQL_CHARCODE#4 environment setting parameter in the queueless job execution environment setting

Data accepted from the scheduler service

Transfer file data

Result file data

Reply data to the scheduler service

M, A

The LANG environment variable when the JP1/AJS3 Autonomous Agent service and the JP1/AJS3 Autonomous Agent Messenger service start

Messages output by flexible job processes and the job execution results when the LANG environment variable is not specified in the login profile of the root user

M, A

Legend:

M: JP1/AJS3 - Manager

A: JP1/AJS3 - Agent

#1

Specify C if you use Chinese.

#2

For details about the commands for manipulating units, see 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

#3

Specify the character encoding that is specified in the AJSCHARCODE environment setting parameter of the scheduler service where the unit to be manipulated by the command is defined. If you use Chinese, specify a value that corresponds to the GB18030 character encoding.

#4

If the manager host and the agent host use different character encodings, the AJSQL_CHARCODE environment setting parameter must be specified to enable character encoding conversion. For details about character encoding conversion for a queueless job, see 7.2.2 Environment settings for executing queueless jobs.

#5

For details about the commands used to operate execution agents, see 1.5.5 Commands used to operate execution agents in the manual JP1/Automatic Job Management System 3 Command Reference.

The following figure shows the sections affected when the character encoding is changed.

Figure 2‒47: Sections affected when the character encoding is changed

When you specify a character encoding in JP1/AJS3 - Web Console, you must set the same character encoding for the definition files and environment variables listed in the table below.

Table 2‒34: Locations of the character encoding setting (JP1/AJS3 - Web Console)

Settings (definition files and environment variables)

What the change affects

The LANG environment variable applied when the JP1/AJS3 HTTP Server service starts#1

The character encoding of internal logs that are output by JP1/AJS3 HTTP Server.

The LANG environment variable applied when the JP1/AJS3 Web Application Server service starts#1

The character encoding of internal logs that are output by JP1/AJS3 Web Application Server.

Environment definition file

The language type setting for the messages output to logs specified in /etc/opt/jp1ajs3web/conf/ajs3web.conf #2

The character encoding of messages that are output to the integrated trace log, command log, and application server log.

#1

If automatic startup is enabled, the value specified in the LANG= line in the service automatic start script is applied.

#2

If the setting is system, the character encoding specified in the LANG environment variable at the start of the JP1/AJS3 Web Application Server service is applied.

(7) Cautionary notes when Japanese is used as a language type

The following provides cautionary notes when Japanese is used as a language type.

(a) Available characters

If the language type is Japanese, you can use the following characters with JP1/AJS3:

ASCII and JIS characters

Single-byte katakana characters

JIS X 0208-1990

Some characters cannot be used with the following character encodings:

If the encoding is SJIS, EUC, or UTF-8:

External characters and machine-dependent characters cannot be used.

If the encoding is EUC:

If the character encoding used in JP1/AJS3 - Manager is EUC, the following characters cannot be used:

If the character encoding is UTF-8:

If the character encoding used in JP1/AJS3 - Manager is UTF-8, the following characters cannot be used:

Note that if the OS is UNIX, all text information used in JP1/AJS3 must be specified by using UTF-8-encoded strings in the shortest form. That text information includes unit names, file names, file contents, messages to be output during job execution, conditions for monitoring event jobs to be run, and information to be passed to event jobs. If a non-shortest form is used, JP1/AJS3 might be unable to operate correctly.

The 3rd level and 4th level Kanji characters added in JIS 2004 cannot be used.

(b) Cautionary notes when mixed types of character encodings exist

Cautionary notes when the manager host and agent host have different character encodings

If the language type is Japanese or English, and the manager host and agent host have different character encodings, the character encodings are converted to the one used by the communication destination when the manager host communicates with the agent host. The following lists the definitions, input files, and execution results whose character encodings are converted. That is, if data is transmitted from the manager to the agent, the data is converted to the character encoding used at the agent. If data is transmitted from the agent to the manager, the data is converted to the character encoding used at the manager. This conversion of the character encoding occurs for the following definitions, input files, and execution results.

For PC jobs, Unix jobs, flexible jobs, and QUEUE jobs

Definitions

Name of executable file

Command statement

Parameter

Script file name

Environment variable

Environment variable filename

Name of the work directory used during agent process execution

Standard input filename

Standard output filename

Standard error output filename

Transfer filename

Job name (for QUEUE job)

Values of macro variables defined in jobs

Input files

Contents of transfer files 1 to 4

Execution results

Contents of the standard output file

Contents of the standard error output file (execution result details)

HTTP connection jobs

Definitions

Conn. configuration file name

Trans. info. file name

Trans. info. file name (URL parameter)

Trans. info. file name (message body)

Status file name

Received header file name

Received body file name

Standard output file name

Standard error output file name

Execution results

Contents of the standard output file

Contents of the standard error output file (execution result details)

Action jobs and custom jobs

Definitions

Information defined for jobs

Values of macro variables defined in jobs

Execution results

Contents of the standard error output file (execution result details)

Event jobs

Definitions

Information defined for jobs

Execution results

Contents of the standard error output file (execution result details)

Inherited information (values of macro variables defined in jobs)

In the case of Chinese, the character encoding is not converted at the time when the manager host communicates with the agent host. All the manager hosts and agent hosts must have the Chinese character encoding.

Cautionary notes when mixed Japanese character encodings are used

The following restrictions apply to combining different types of Japanese character encodings.

Remote execution of commands

When a command is remotely executed, the same character encoding must be set for the host where the command is entered and for the host where the command is executed.

If the character encoding on the host where the command is executed is UTF-8, you can remotely execute the command by setting EUC as the character encoding of the host where the command is entered.

For details about remote execution of commands, see 1.1.7 Remote execution of a command in the manual JP1/Automatic Job Management System 3 Command Reference.

The character encoding of the host where the command is entered is the character encoding specified in the OS by using the LANG environment variable, for example.

The character encoding of the host where the command is executed refers to one of the following:

Character encoding specified in the AJSCHARCODE environment setting parameter

Setting of the OS used when the JP1/AJS3 service is started

Remote jobnet

When a remote jobnet is executed, the character encodings of the host where the remote job is defined and the host where the remote job is executed must match.

The character encoding of the host where the remote job is defined and the character encoding of the host where the remote job is executed refer to one of the following:

Character encoding specified in the AJSCHARCODE environment setting parameter on each host

Setting of the OS used when the JP1/AJS3 service is started

Unix job, HTTP connection job, flexible job, action job, and event job

For JP1/AJS3 - View or a command, if the definition items for a job executed on the agent host in a UTF-8 environment contain Japanese characters, assume that one Japanese character requires 4 bytes. Based on this assumption, define the job so that the maximum value for each item is not exceeded. If sjis is specified for the DEFLENTYPE environment setting parameter, the maximum number of characters that can be specified for the following items is the same as in a Shift-JIS environment:

Unit name in the detailed unit definition

Comment in the detailed unit definition

Exclusive jobnet in the schedule settings

A Unix job, action job, or event job can be executed in a system configuration where the manager host operates in a Shift-JIS or EUC environment and the agent host operates in a UTF-8 environment. In this case, the number of bytes converted to the character encoding of the agent host is checked as the size of the information defined for the job. As a result, a job execution error might occur even if the definition in JP1/AJS3 - View or a command does not exceed the maximum number of bytes that can be entered for job items.

Event job

If the sum of the size of the event job passing information and the size of the macro variable name exceeds 4,096 bytes on the agent host, the excess data is truncated.

To pass information containing Japanese characters in a UTF-8 environment, assume that one Japanese character requires 4 bytes.

To use JP1/AJS3 that does not support UTF-8 to receive JP1 events issued from a UTF-8 environment, configure JP1/Base to run in character encoding compatibility mode. If you do not use character encoding compatibility mode, a JP1 event might not be detected correctly or another kind of error might occur.

For details on the character encoding compatibility mode, see JP1/Base User's Guide.

Commands used for executing submit jobs

If a command is executed from a host in a Shift-JIS or EUC environment for a manager host in a UTF-8 environment, an error might occur on the manager host even when the values of the options do not exceed the maximum number of bytes on the command execution host. The reason for the error is that the number of bytes in the option values containing Japanese characters increases due to character encoding conversion when the command execution host transfers data to the manager host.

Therefore, when you specify option values containing Japanese characters for commands executed on the manager host in the UTF-8 environment, assume that one Japanese character require 4 bytes. Based on this assumption, specify the options so that the value of each option is within the maximum number of specifiable bytes.

Commands:

jpqjobsub, jpqjobcan, jpqjobalt, jpqjobmove, jpqjobget, jpqjobshow, jpqendjobshow, jpqjobdel, jpqqueopen, jpqqueclose, jpqqueshow, jpqqueadd, jpqquedel, jpqquealt, jpqagtlink, jpqagtunlink, jpqagtshow, jpqagtadd, jpqagtdel, jpqagtalt, jpqresshow, jpqresadd, jpqresdel

Notes on using UTF-8 encoding

If a command entered from a host that uses UTF-8 encoding is remotely executed on a host for which UTF-8 is specified as the character encoding in AJSCHARCODE, you must specify no for the AJSCONVERTUTF8 environment variable. If the AJSCONVERTUTF8 environment variable is not specified or if the command is remotely executed with yes specified, characters in the display results might be garbled or processing on the unit might not be performed correctly.

For details about the AJSCONVERTUTF8 environment variable, see 1.4 Environment variables in the manual JP1/Automatic Job Management System 3 Command Reference.

For details about the characters that you can use in a UTF-8 environment, see (a) Available characters.

If a queueless job entered from the manager host that uses UTF-8 encoding is executed on an agent host that does not support UTF-8 encoding, you must specify the QLMANCHARCODE environment setting parameter on the manager host. For details about the QLMANCHARCODE environment setting parameter, see 20.10 Setting up the queueless job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

If UTF-8 encoding is used and sjis is specified for the DEFLENTYPE environment setting parameter, the number of characters that can be specified for the following items is the same as in a Shift-JIS environment:

Unit name in the detailed unit definition

Comment in the detailed unit definition

Exclusive jobnet in the schedule settings

Note, however, that the maximum number of nested units (maximum number of levels) is 10 (the default is 30).

For a version of JP1/AJS3 - View earlier than 09-50, if sjis is specified for the DEFLENTYPE environment setting parameter, a scheduler service and its lower units are not displayed. If sjis is specified for the DEFLENTYPE environment setting parameter for all scheduler services, the KAVV187-E message is output and none of the scheduler services or their lower units are displayed. If you use the ajs command or manager jobnet to access the scheduler service for which sjis is specified for the DEFLENTYPE environment setting parameter, the KAVV455-E message is output. The scheduler service and its lower units are not displayed.

(8) Cautionary notes when the Chinese language type is used

Only GB18030-2000 characters of 2 bytes or less can be used. Operation is not guaranteed if any other character is used.

Cautionary note

When using the Chinese language, the following characters might not be displayed correctly:

Euro symbol (code:0xA2E3)

Comma (code:0xA6D9) #

Period (code:0xA6DA) #

Punctuation mark (code:0xA6DB) #

Colon (code:0xA6DC) #

Semicolon (code:0xA6DD) #

Exclamation mark (code:0xA6DE) #

Question mark (code:0xA6DF) #

Left black lenticular bracket (white) (code:0xA6EC) #

Right black lenticular bracket (white) (code:0xA6ED) #

Ellipses (code:0xA6F3) #

#

For vertically written text.

(9) Cautionary notes common to all the language types

If you use an unsupported character in a definition item, such as a unit name, the following problems might occur. Unsupported characters cannot be used even in a stand-alone configuration.

Characters are garbled.

An error occurs during the creation of a new unit or redefinition of a unit.

A standard job and HTTP connection job are placed in the Ended abnormally status or operate incorrectly.

An event job is placed in the Ended abnormally status, cannot be detected, or is detected incorrectly.

A JP1/AJS3 process terminates abnormally.

Make sure that the data or files listed below do not contain unsupported characters. If there are any unsupported characters, the same problems as when unsupported characters are used in definition items might occur.

Data stored in the passing information#1

Data that is output to the standard error output and standard output#2

Standard input file, environment variable file, or transfer file#3

Text file or list file specified for sending an email#4

#1

Applicable for the following passing information:

The information on which passing information is specified in the event job definition for passing the event information received by an event job to a succeeding job or jobnet

For details about how to pass the information received by an event job, see 2.4.4(6) Passing information received by an event job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

Passing information specified by a passing information settings job

For details about the passing information settings job, see 2.4.9 Passing information that changes dynamically to a succeeding unit (example of defining a jobnet that uses a passing information setting job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

#2

Applicable when the data is in the job execution results specified for a PC job, Unix job, or flexible job. For details about the standard error output and Standard output, see 12.4.6 Define Details - [UNIX Job] dialog box in the JP1/Automatic Job Management System 3 Operator's Guide, or 12.4.7 Define Details - [PC Job] dialog box in the JP1/Automatic Job Management System 3 Operator's Guide.

#3

Applicable when the file is specified for a PC job or Unix job. For details about the standard input file, environment variable file and transfer file, see 12.4.6 Define Details - [UNIX Job] dialog box in the JP1/Automatic Job Management System 3 Operator's Guide, or 12.4.7 Define Details - [PC Job] dialog box in the JP1/Automatic Job Management System 3 Operator's Guide.

#4

Applicable when PC is specified as the platform in the definition items. For details about the mail linkage, see 2. Linking Mail Systems in the JP1/Automatic Job Management System 3 Linkage Guide.

(10) Changing the language setting during operation

If you change the language type and character encoding during operation, reinstallation of JP1/AJS3 might be required depending on the combination of JP1/AJS3 and the OS. The following table lists the combination of JP1/AJS3 and the OS and whether reinstallation is required.

Table 2‒35: Combination of JP1/AJS3 and the OS and whether reinstallation is required

Product

Windows

UNIX

JP1/AJS3 - Manager

Reinstallation is required.

Reinstallation is required.

JP1/AJS3 - Agent

Reinstallation is required.

Reinstallation is not required.

JP1/AJS3 - View

Reinstallation is required.

Not supported.

If reinstallation is required, migrate the setting information in accordance with the backup and recovery procedures. If reinstallation is not required, stop the JP1/AJS3 service, change the environment settings, and then cold-start the JP1/AJS3 service.

For details about how to change the character encoding, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide.

(11) About the operations in multiple language environments

Korean, German, French, Spanish or Russian can be used for the unit name and the comment in JP1/AJS3. When using multiple languages, please set the same language for the OSs on which JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, JP1/AJS3 - Web Console will be installed. Also, please set the same language and character code for JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, JP1/AJS3 - Web Console. If the settings of language and character code are different to connection products, please use unit name and comment in the range of ASCII code.

Note: If you are using the Russian language, you cannot set the same character encoding between Windows and Linux products, because Windows and Linux products use different character encodings. Therefore, the OSs used should be uniformly set to either Windows or Linux.

The following shows the procedure for specifying the settings required to use Korean, German, French, Spanish, or Russian. For details about how to change the language settings in the OS, see the Release Notes. For details about how to change the character encoding, see 7.9.6 Changing the language environment of the system in the JP1/Automatic Job Management System 3 Administration Guide.

(a) In Windows

For JP1/AJS3 - Manager and JP1/AJS3 - Agent

The detailed procedure for definition is as follows:

Change the language settings in the OS.

Install JP1/AJS3 - Manager or JP1/AJS3 - Agent.

Execute the following command:

jajs_config -k "[JP1_DEFAULT\JP1AJS2COMMON]" "AJSI18N"="yes"

For JP1/AJS3 - View

The detailed procedure for definition is as follows:

Change the language settings in the OS.

Install JP1/AJS3 - View.

In the environment settings file (ajs.conf), add the SetCharEncodingNameI18N definition line, and then specify the appropriate value as shown in the following table.

File storage folder

JP1/AJS3-View-installation-folder\conf\ajs.conf

Table 2‒36: Values that can be specified in the environment settings file (ajs.conf)

Language

Connection destination JP1/AJS3 - Manager OS

Value that can be specified for SetCharEncodingNameI18N

Korean

Windows

EUC_KR

Linux

EUC_KR

German

French

Spanish

Windows

ISO8859_1

Linux

ISO8859_1

Russian

Windows

CP1251

Linux

KOI8_R

Example: When using German language

Change from:

[STARTUP]
lang=1

Change to:

[STARTUP]
lang=1
SetCharEncodingNameI18N=ISO8859_1

For JP1/AJS3 - Web Console

The detailed procedure for definition is as follows:

Change the language settings in the OS.

Install JP1/AJS3 - Web Console.

Specify the value in the following table for the I18N definition line of the environment settings file (ajscharcodemapping.properties).

File storage folder

Web_Data_Path#\conf\ajscharcodemapping.properties

File storage folder for operation in a cluster system

shared-folder\jp1ajs3web\conf\ajscharcodemapping.properties

#

One of the following paths is indicated in Web_Data_Path:

If the installation folder is the default installation folder or is in a folder protected by the system:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\jp1ajs3web

The default value for %ALLUSERSPROFILE% is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

If the installation folder is other than the above:

JP1/AJS3 - Web Console-installation-folder

Table 2‒37: Values that can be specified in the environment settings file (ajscharcodemapping.properties)

Language

Connection destination JP1/AJS3 - Manager OS

I18N value

Korean

Windows

EUC_KR

Linux

EUC_KR

German

French

Spanish

Windows

ISO8859_1

Linux

ISO8859_1

Russian

Windows

CP1251

Linux

KOI8_R

Example: When using German language

Change from:

C=ASCII
SJIS=MS932
EUC=EUC_JP
UTF-8=UTF8
I18N=GB18030

Change to:

C=ASCII
SJIS=MS932
EUC=EUC_JP
UTF-8=UTF8
I18N=ISO8859_1

(b) In Linux

For JP1/AJS3 - Manager and JP1/AJS3 - Agent

The detailed procedure for definition is as follows:

Specify C for LANG environment variable.

export LANG=C

Install JP1/AJS3 - Manager or JP1/AJS3 - Agent.

JP1/AJS3 - Manager or JP1/AJS3 - Agent is installed with English language settings.

Use the jajs_config command to set yes for the AJSI18N environment setting parameter.

jajs_config -k "[JP1_DEFAULT\JP1AJS2COMMON]" "AJSI18N"="yes"

Change the value of the LANG environment variable that is defined in the JP1/AJS3 environment definition file (jp1ajs_env.conf).

For a physical host:

/etc/opt/jp1ajs2/conf/jp1ajs_env.conf

For a logical host:

shared-directory/jp1ajs2/conf/jp1ajs_env.conf

Table 2‒38: Values that can be specified in the LANG environment variable

Language

Character encoding

Value of LANG environment variable

Korean

EUC-KR

ko_KR.EUC-KR

German

ISO-8859-1

de_DE.ISO-8859-1

French

ISO-8859-1

fr_FR.ISO-8859-1

Spanish

ISO-8859-1

es_ES.ISO-8859-1

Russian

KOI8-R

ru_RU.KOI8-R

Example: When using German language

Change from:

LANG=C

Change to:

LANG=de_DE.ISO-8859-1

For JP1/AJS3 - Web Console

The detailed procedure for definition is as follows:

Specify C for LANG environment variable

export LANG=C

Install JP1/AJS3 - Web Console

JP1/AJS3 - Web Console is installed with English language settings.

Specify the value in the following table for the I18N definition line of the environment settings file (ajscharcodemapping.properties).

Specified place

/etc/opt/jp1ajs3web/conf/ajscharcodemapping.properties

Cluster configuration

shared-directory/jp1ajs3web/conf/ajscharcodemapping.properties

Table 2‒39: Values that can be specified in the environment settings file (ajscharcodemapping.properties)

Language

Connection destination JP1/AJS3 - Manager OS

I18N value

Linux

Windows

EUC_KR

Linux

EUC_KR

German

French

Spanish

Windows

ISO8859_1

Linux

ISO8859_1

Russian

Windows

CP1251

Linux

KOI8_R

Example: When using German language

Change from:

C=ASCII
SJIS=MS932
EUC=EUC_JP
UTF-8=UTF8
I18N=GB18030

Change to:

C=ASCII
SJIS=MS932
EUC=EUC_JP
UTF-8=UTF8
I18N=ISO8859_1

(c) When adding a scheduler service or logical host (for JP1/AJS3 - Manager only)

When you add a scheduler service or logical host in Windows or Linux, use the following procedure to change the language type settings.

Run the jajs_setup or jajs_setup_cluster command to add a scheduler service.

For details about the jajs_setup command, see jajs_setup in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

For details about the jajs_setup_cluster command, see jajs_setup_cluster in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

For the scheduler service that you added, change the value of the AJSCHARCODE environment setting parameter to C.

Execute the following command:

jajs_config -k " [{JP1_DEFAULT|logical-host-name}\JP1AJSMANAGER\scheduler-service-name]" "AJSCHARCODE"="C"

2.5 Setting the job execution environment

The JP1/AJS3 job execution environment consists of manager hosts, which manage job definitions and distribute jobs to execution hosts, and agent hosts, which execute the distributed jobs.

To execute jobs, information about the agent hosts must be registered in the manager host. In JP1/AJS3, the agent hosts that execute jobs are managed by logical names, referred to as execution agent names. To determine where to distribute each job, the manager host maps the execution agent name defined in the job with the physical host name in the registered agent host information.

2.5.1 Defining execution agents

Consider the following points when defining the agent host information to be registered in the manager hosts.

(1) Assigning execution agent names and execution host names

The agent host information to be registered in a manager host consists of the logical names of the agent hosts (execution agent names) and the physical name of the execution host. Assign each execution host an execution agent. A maximum of 1,024 execution agents can be registered in one manager host. You can increase the maximum number of agent hosts to 2,048.

When defining a job or jobnet, specify the execution agent name as the host on which the job is to be executed. The manager host references the registered execution agent information, and sends the job to the execution host corresponding to the execution agent name defined in the job or jobnet. Thus, when the agent host configuration needs to be changed due to an increase or decrease in work volume, rather than having to change the job or jobnet definition, you can simply change the execution agent information registered on the manager host without disrupting JP1/AJS3 operations.

(2) Maximum number of concurrently executable jobs

The number of concurrently executable jobs on an agent host can be restricted according to the resources available for that host. The setting applies to Unix jobs (other than queueless jobs), PC jobs (other than queueless jobs), flexible jobs, HTTP connection jobs, action jobs, custom jobs, and Passing information settings jobs.

The maximum number of concurrently executable jobs can be specified for particular time periods (set in 30-minute units). The default setting is 00:00-00:00=5 (maximum of five concurrent jobs, 24 hours a day).

For example, if you specify 08:00-17:30=5, a maximum of five jobs can be executed concurrently during the time period 8:00 to 17:30. By adjusting the maximum number of concurrent jobs in this way, you can distribute the processing load at certain times of the day.

When the number of jobs to be executed reaches the maximum number of concurrently executable jobs, additional jobs are queued on the manager host.

Cautionary notes

If you do not specify the maximum number of concurrently executable jobs when adding an execution agent, the default (maximum of five concurrent jobs, 24 hours a day) is used. This setting does not affect operation if you execute jobs with short execution times or register only a few jobs for execution at the same time. However, if you execute jobs with long execution times or register many jobs at the same time, the number of concurrent jobs will quickly reach the maximum, and remain there for a extended periods of time. This might affect the execution of subsequent jobs.

When the maximum number of concurrently executable jobs is reached on an agent host, subsequent jobs are made to wait in the queuing status until the active jobs finish. In such cases, the time the jobs end is later than the scheduled time. Taking the job execution time and the number of jobs executed per unit of time into consideration, in addition to considering resources on the agent host, consider setting a large value for the maximum number of concurrently executable jobs.

The maximum number of concurrently executable jobs you specify applies to each execution agent. If an execution host is connected by using different execution agent names, jobs equal to the total of the maximum number of concurrently executable jobs specified for these execution agents will be executed concurrently on that execution host.

For example, suppose that the same execution host is specified for an execution agent with 00:00-00:00=10 (maximum of 10 concurrent jobs, 24 hours a day) set, and an execution agent with 00:00-00:00=5 (maximum of five concurrent jobs, 24 hours a day) set. In this case, a maximum of 15 jobs can be executed concurrently.

When you specify a maximum number of concurrently executable jobs, specify a value appropriate for the execution host.

(3) Default execution agent

By default, the local host is set as an agent host in the information registered in the manager host. This agent is referred to as the default execution agent.

The agent host information defined as the default execution agent is as follows:

Table 2‒40: Information defined as the default execution agent

No.

Item

Setting

1

Execution agent name

@SYSTEM

2

Execution host name

Manager host name

3

Maximum number of concurrently executable jobs

5 (00:00-00:00=5)

4

Restricting job transfer

Jobs can be accepted and transferred to the execution host.

This default execution agent can be used to execute jobs on a manager host. It is also used when no execution agent is specified in the job or jobnet definition.

To change the default execution agent definition, use the ajsagtalt command or JP1/AJS3 - Web Console. For details about the command, see ajsagtalt in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

Cautionary note

In JP1/AJS2, when the manager host name was specified, jobs were automatically executed on the default manager host. In JP1/AJS3, if you want to specify the local host name to execute jobs, you need to add an execution agent, other than the default execution agent, that has the same name as the local host name. Note, however, that if you migrate the unit definition to another manager host when the local host name is specified, you need to change the Exec-agent setting to the destination host name. For this reason, we recommend that you use the default execution agent to execute jobs on the local host.

(4) Adding a execution agent

Execution agents must be added for the number of agent hosts on which you want to execute jobs because only the default execution agent is created on the manager host immediately after setup.

Use the ajsagtadd command or JP1/AJS3 - Web Console to add an execution agent. You can also add multiple execution agents in one operation. For details about the procedure, see 4.1 Execution agent settings in the JP1/Automatic Job Management System 3 Configuration Guide. To add multiple execution agents collectively, see the description of the -f option in ajsagtadd in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(5) Defining an agent automatically

When the setting for automatically defining an agent is enabled, the execution agent (assigned execution agent name and execution host name) that has the same name as the execution agent name specified in the job's Define Details dialog box is automatically added to the manager host.

For details about the agent automatic definition function, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary notes

We recommend that the system administrator set the agent automatic definition function when setting up JP1/AJS3. When this function is enabled to execute jobs, make sure that only users who have both JP1_JPQ_User and JP1_JPQ_Admin permissions can execute jobs.

When you use the agent automatic definition function and the execution agent restriction function, an execution agent that is automatically defined during job execution needs to be set in the execution agent profile before execution of the job. If the execution agent has not been set, the job is placed in the Failed to start status, in which case the execution agent will not be added.

(6) Execution agent restriction

You can use the execution agent restriction functionality to set an execution agent that is permitted to execute jobs for each unit.

By setting permitted execution agents in an operation profile called the execution agent profile, you can prevent jobs from being executed on the wrong execution agents.

For details about setting an execution agent profile, see 21.1.1 Setting execution agent restrictions in the JP1/Automatic Job Management System 3 Configuration Guide.

(a) Overview of execution agent restriction

When the execution agent profile is enabled, whether the execution agent specified in the job's Define Details dialog box has been set in the execution agent profile is checked when:

A unit is defined in JP1/AJS3 - View

A definition pre-check is performed by using the ajschkdef command

A job is executed

If the specified execution agent is not set in the execution agent profile, a definition error occurs or the job is placed in the Failed to start status if execution is attempted.

The following figure shows an example of using the execution agent restriction functionality.

Figure 2‒48: Example of using the execution agent restriction functionality

In this example, execution agent AGT1, which is permitted to execute jobs in jobnet net1, and execution agent AGT2, which is permitted to execute jobs in jobnet net2, are set in the execution agent profile. Jobs /net1/job1 and /net2/job1 are executed because permitted execution agents are specified. In the case of job /net1/job2, execution is suppressed because execution agent AGT2, which is not permitted to execute the job, is specified. In the case of job /net2/job2, because no execution agent is specified, an attempt is made to execute the job on the manager host (default execution agent), but the attempt is suppressed. If you want to execute jobs on the manager host without specifying the execution agent during definition of the unit, you need to set the default execution agent name in the execution agent profile.

Note that the execution agent is not checked for units that are not set in the execution agent profile.

Applicable units

You can check whether the execution agent specified in the Define Details dialog box for the unit is set in the execution agent profile for the following units:

Root jobnet#1

Nested jobnet#1

Unix job

PC job

Flexible job#2

HTTP connection job

Event job

Action job

Custom job

#1

Checking is performed only if the execution agent was specified before the unit was defined in JP1/AJS3 - View.

#2

A flexible job uses a relay agent not an execution agent. If you do not use a relay function of a flexible job, permit @SYSTEM or define and permit an execution agent for the relay agent for a flexible job.

How to check the execution agent

If execution agent restriction is used, the execution agent is checked when a unit is defined in JP1/AJS3 - View, when a definition pre-check is performed by using the ajschkdef command, and when a job is executed.

The following describes how the check is performed for each case.

When a unit is defined in JP1/AJS3 - View

In the Define Details dialog box for the unit, the Exec-agent combo box displays the execution agents set in the execution agent profile. You can either select a displayed execution agent or type an agent name in the combo box. Click the OK button to check whether the specified execution agent is set in the execution agent profile.

You can also specify that checking is to be performed only when a unit is defined, and suppress checking when a job is executed.

Note, however, that in the Define Details - [Flexible Job] dialog box, the combo box that displays the execution agents set in the execution agent profile is not displayed in the Relay agent. In addition, when you click the OK button, you are not asked whether the specified execution agent is set in the execution agent profile.

When a definition pre-check is performed by using the ajschkdef command

When a definition pre-check is performed, the execution agent profile is checked to see whether the execution agent has been set. If an execution agent that has not been set, the check result information is output to the check result file.

Note that the ajschkdef command with the -C and -p options specified allows you to check the execution agent irrespective of whether the execution agent profile is enabled or disabled.

When a job is executed

When a job is executed, the execution agent profile is checked to see whether the execution agent is set. If an attempt is made to execute the job on an execution agent that has not been set, the job is placed in the Failed to start status. Note, however, that when one of the event jobs defined in the start conditions causes an error during the execution agent check, jobs are placed in one of the following statuses:

Monitoring generation of the jobnet with start conditions:

Monitor terminated status

The job causing the error during the execution agent check:

Failed to start status

Jobs defined in the start conditions other than the job described above:

Not executed + Ended status

You can also specify that checking is performed only when a job is executed, and that checking is suppressed when a unit is defined.

(b) Permitted execution agents

When you specify units on multiple levels in the execution agent profile, the execution agent specified for a lower-level unit must be permitted for all upper-level units.

The following figure shows the relationship between the execution agent profile settings and the permitted execution agents.

Figure 2‒49: Execution agent profile settings and permitted execution agents

In this example, Job A can be executed only on execution agent AG1, which is permitted for the scheduler service, Root Jobnet A, and Nested Jobnet A. Job D can neither be defined nor executed because an execution agent is not permitted for any of the upper-level units of Job D. Execution agent profiles with such settings will be handled as a syntax error when an attempt is made to enable the execution agent restriction.

To prevent the execution agent check process from affecting tasks when a permitted execution agent is specified for units in multiple levels, we recommend that the execution agent be specified for no more than the following levels:

Scheduler service

Units directly under the scheduler service

When permitting execution on the local host

@SYSTEM must be specified. Note, however, that if you want to permit an execution agent that has the same name as the local host name, specify the execution agent name.

If you want to permit execution of queueless jobs on the local host, specify the local host name. Hereafter, local host name refers to names that can be checked by using the following methods.

Physical host:

The host name determined by executing the hostname command

Logical host (Windows):

On the host where JP1/AJS3 is running, in Control Panel, either choose Services, or choose Administrative Tools and then Services. In the Services dialog box that opens, the host name is displayed as xxxxx in JP1/AJS3_xxxxx.

Logical host (UNIX):

Execute the ps command. The host name is displayed after the jajs_spmd process.

When specifying an execution agent group as the unit execution agent

To specify an execution agent group as the execution agent for units, set the name of the execution agent group name that will be permitted to execute jobs in the execution agent profile.

The following figure shows an example of setting an execution agent group in the execution agent profile.

Figure 2‒50: Setting an execution agent group in the execution agent profile

In this example, when either AGTGRP1 or AGT1 is specified as the execution agent for the jobs in /Grp1/net1/, the jobs will actually be executed on execution agent AGT1 (execution host host1). However, because AGT1 is not specified in the execution agent profile, specifying AGT1 as the execution agent for the jobs result in an error during the execution agent check.

When specifying a macro variable name for the unit execution agent

To specify a macro variable name for the unit execution agent, set the name of an execution agent or a macro variable name permitted to execute in the execution agent profile, depending on the point at which execution agent restriction is to be checked.

The following table describes the information that needs to be set in the execution agent profile when a macro variable name is specified.

Table 2‒41: Execution agent profile settings when a macro variable name is specified

No.

Restriction checked when a unit is defined (View)

Restriction checked when a job is executed (JobExec)

Definition or execution is permitted for:

1

No (off)

Yes (on)

Execution agent name

2

Yes (on)

No (off)

Macro variable name

3

Yes (on)

Yes (on)

Macro variable name

Execution agent name

We recommend you use a combination of Nos. 1 and 2 to set the execution agent profile.

For queueless jobs

To use the execution agent restriction functionality for a queueless job, set the name of the host on which the queueless job will be executed in the execution agent profile.

If the target host with a class name is specified in Exec-agent in the Define Details dialog box, you do not need to set the !class-name portion in the execution agent profile.

If a logical host that has not been attached is specified as the execution host for the queueless job, the queueless job is executed on the physical host corresponding to the logical host when the following conditions exist:

The logical host specified for the queueless job has been set in the execution agent profile.

exec is set in the AJSQL_NOATTACHREQ environment setting parameter.

Whether the physical host is set in the execution agent profile does not matter. Even if the physical host is not defined in the execution agent profile, the queueless job can be executed on the physical host.

(c) Cautionary notes

The execution agent restriction functionality can be used when the version of JP1/AJS3 - Manager and JP1/AJS3 - View is 09-50 or later.

The system does not check the execution agent when a unit is created by using one of the methods below. If you want to check the execution agent, you will need to perform a pre-check.

Copying and pasting a unit, or cutting and pasting a unit

Restoring a backed-up unit

Distributing a unit by using JP1/Software Distribution or JP1/FTP

Before executing a job, make sure that the execution agent or the execution agent group that has been set in the execution agent profile is defined in JP1/AJS3 - Manager. If they are not defined in JP1/AJS3 - Manager, no error occurs when the unit is defined, but an error occurs when pre-check is performed or when a job is executed.

When you use the agent automatic definition function and the execution agent restriction function, an execution agent that is automatically defined during job execution needs to be set in the execution agent profile before execution of the job. If the execution agent has not been set in the execution agent profile, the job is placed in the Failed to start status, in which case the execution agent will not be added.

An execution agent specified for a remote jobnet and subordinate units must be in JP1/AJS3 - Manager to which the remote jobnet is to be transferred. Therefore, the execution agent is not checked when a unit is defined or when a pre-check is performed. When a job is executed, if the execution agent profile is enabled in the JP1/AJS3 - Manager to which the remote jobnet is to be transferred, the execution agent is checked according to the profile settings.

(7) Increasing the maximum number of execution agents that can be registered in a manager host

By default, the maximum number of execution agents that can be registered in a manager host is set to 1,024. By using the environment setting parameter AGENTLIMITEXTEND, you can increase the maximum number to 2,048.

For details, with Windows hosts, see 6.2.28 Setting to increase the maximum number of execution agents that can be registered in a manager host in the JP1/Automatic Job Management System 3 Configuration Guide. For details with UNIX hosts, see 15.2.25 Setting to increase the maximum number of execution agents that can be registered in a manager host in the JP1/Automatic Job Management System 3 Configuration Guide.

2.5.2 Load distribution

When application servers configure load distribution by using load balancing or a similar technique, load distribution for batch jobs is also possible in JP1/AJS3.

Load distribution can be supported by grouping execution agents and setting the execution agent group name as the execution agent name for jobs. Points to consider when distributing the load in this way are discussed below.

For examples of how to distribute processing loads, and the order in which the execution agent hosts are determined, see 2.3.1 Processing with a distributed load in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(1) Grouping execution agents

Decide which execution agents to group together and the group name.

A maximum of 1,024 execution agents can belong to a group, and a maximum of 1,024 groups can be registered in one manager host.

The manager host references the registered execution agent group information, and determines which execution agent to forward the job to based on the priority of the agents within the execution agent group, and the maximum number of concurrently executable jobs.

(2) Execution agent priority

When you use an execution agent group to support load distribution, you can specify the job distribution priority for each execution agent in the group.

For an execution agent, you can specify a priority in the range from 1 to 16. The lowest priority is 1, and the default is 16 (highest priority).

2.5.3 OS user environment when a job is executed

Note the following when considering the job execution environment.

(1) User account at job execution

In JP1/AJS3, jobs are executed under the OS user account of the destination agent host. The destination agent host has a user mapping definition, which is used to convert the JP1 user who registered the job for execution to the OS user. The job is then executed under the OS user's permissions. The resources referenced or updated by the job process are dependent on the OS security control.

The user account is referenced each time a job is executed. Any changes to the definitions affect jobs executed after the changes are made.

In the Windows version of JP1/AJS3, when a job is executed under a user account other than the account from which the JP1/AJS3 service was started, JP1/AJS3 acquires the user information needed to start the job process. To acquire information about a user, an access token is required. The access token contains user information such as the security groups to which the user belongs and the user's access permissions.

Using Win32 API functions, JP1/AJS3 obtains an access token each time it starts a job, and releases the access token when the job completes execution. When an error occurs in one of these functions, the job is placed in the Failed to start status if the access token could not be acquired, or in the Ended abnormally status if the access token could not be released.

You can keep and reuse an access token if the domain name, user name, and password remain the same.

By reusing access tokens, you can minimize the number of times tokens are acquired and released, thus avoiding the temporary errors caused by the Win32 API functions. This results in fewer jobs ending abnormally. For details, see 6.2.17 Reusing access tokens for job execution in the JP1/Automatic Job Management System 3 Configuration Guide.

(2) OS user environment used for job execution

The OS user environment used to execute jobs is platform-dependent.

When a job is executed on a Windows agent host, the system environment variable normally takes precedence over the user profile information. However, you can enable the user profile information by specifying the environment setting for job execution control. For details, see 6.2.16 Executing a job that requires a user profile in the JP1/Automatic Job Management System 3 Configuration Guide.

When a job is executed on a UNIX agent host, JP1/AJS3 reads the local login script of the OS user mapped from the JP1 user. The OS user's login shell is set as the execution shell of the job, unless otherwise specified in the first line of the script file or command statement.

The OS user environment is read each time a job is executed. Any changes to a definition affects jobs executed after the changes are made.

(3) HP-UX OS user groups

When an OS user who executes jobs belongs to more than one group, and you want to enable access to all these groups, you must set /etc/logingroup; otherwise, only the group ID defined in /etc/passwd can be used.

To enable access to multiple groups, you must copy the /etc/group group definition into /etc/logingroup, or make a symbolic link between /etc/logingroup and /etc/group. For details, see your OS documentation.

Cautionary note

To enable access to multiple groups when the process of a JP1/AJS3 service accesses a job result file or temporary file, see the setting described in 15.2.18 Enabling the file access permission check for the ACL and secondary group settings during job execution in the JP1/Automatic Job Management System 3 Configuration Guide.

If you do not perform this setting, access from a secondary group based on the entries in /etc/logingroup is possible only for a job process. Entries in /etc/logingroup do not apply to a JP1/AJS3 service process accessing a job result file or temporary file. If a JP1/AJS3 service process is unable to access a result file, either change the permission of the directory containing the result file to a permission that will allow access from a secondary group, or change the group that owns the directory or the specified result file from the secondary group to the primary group of the user executing the job. In the case of a temporary file, change the permission of the work directory to a permission that will allow access from a secondary group.

For details, see 2.6.2(3) Executing a standard job, action job, or custom job results in an abnormal end in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(4) Access permission to job executable files and script files

For a job executed on a Windows agent host, set the access permission for the executable file in the JP1/AJS3 service account. You do not need to grant access permission to the OS user executing the job.

For a job executed on a UNIX agent host, grant access permission to the executable script file to the OS user.

(5) Login shell at job startup (Unix jobs, flexible jobs, HTTP connection jobs, and action jobs)

If the execution host (agent) is a UNIX host, the system executes the OS user's login shell (contents of the /etc/passwd file) at the destination agent host when a job is started. If no login shell is defined, /bin/sh is executed. In JP1/AJS3, sh, csh, and ksh can be used as login shells (For Linux, in addition to the csh, the bash can also be used). See the following precautions on using shells other than these three.

(a) Precautions for Unix jobs and flexible jobs

If you use a login shell other than sh, csh, ksh or bash, the login script might not be executed under certain OSs. Consequently, because the environment variable settings for the user executing the job are not applied, jobs might terminate abnormally, or return unexpected results. To avoid such problems, specify the environment variable settings required for executing a job script.

To check whether the environment variables needed for job execution are set properly, create a shell script that writes the execution results returned by the env command to a file, and then look at the contents of the file that is output when you execute this script as a job.

(b) Common precautions for jobs

Some shells, such as bash, do not initialize signal processing to the default status. As a result, jobs might terminate abnormally, or return unexpected execution results. In this case, use the sh, csh, or ksh shell instead.

Signal processing can be initialized to the default status by changing a setting as described in 15.2.17 Applying SIG_DFL (setting for receiving the SIGCHLD signal) to a child process started from JP1/AJS3 in the JP1/Automatic Job Management System 3 Configuration Guide. If you are performing a new installation of JP1/AJS3 or JP1/AJS2 version 08-00 or later, there is no need to change the setting because jobs are executed in these versions with the default setting (SIG_DFL) which allows child processes to receive SIGCHLD signals.

2.5.4 Maximum number of concurrently executable jobs

In JP1/AJS3, you can set the maximum number of jobs that an agent host can execute concurrently. When this maximum is reached, subsequent jobs are placed in a wait status. By setting a maximum number of concurrently executable jobs, you can distribute the load during set time periods, or among multiple agent hosts when more than one agent host is connected.

The maximum number of concurrent jobs must be specified per execution agent. You cannot perform this setting for an execution agent group. The setting applies to Unix jobs (other than queueless jobs), PC jobs (other than queueless jobs), flexible jobs, HTTP connection jobs, action jobs, custom jobs, and Passing information settings jobs.

For the procedure and notes on setting a maximum number of concurrently executable QUEUE jobs and submit jobs, see 7.1.1(4) Notes on the execution environment required for QUEUE jobs and submit jobs.

(1) Notes on setting a maximum number of concurrently executable jobs

The following provides notes on setting a maximum number of concurrently executable jobs:

You can set and change the maximum number of concurrently executable jobs using the ajsagtadd command or ajsagtalt command. To check the current setting, use the ajsagtshow command. You can also perform these operations from JP1/AJS3 - Web Console.

If you add an execution agent using the ajsagtadd command, but do not specify a maximum number of concurrently executable jobs, the default setting 00:00-00:00=5 (maximum of five concurrent jobs, 24 hours a day) is assumed.

The default setting will suffice if only short jobs are executed, and no more than a few jobs will be registered for execution simultaneously. However, if you execute jobs with long execution times or register many jobs at the same time, the number of concurrent jobs will quickly reach the maximum, and remain there for extended periods of time. This might affect the execution of subsequent jobs.

When the maximum number of concurrently executable jobs is reached on an agent host, subsequent jobs are made to wait in the queuing status until the active jobs finish. In such cases, jobs will take longer than expected to execute. Take the job execution time and the number of jobs executed per unit time into consideration when you set the maximum number of concurrently executable jobs.

The maximum number of concurrently executable jobs you specify applies to each execution agent. If different execution agents are mapped to the same execution host, the sum of the maximum number of concurrently executable jobs specified for these execution agents is set for the jobs that will be executed on that execution host.

As an example, take the addition of an execution agent that uses the local host name and whose maximum number of concurrently executable jobs is set to 00:00-00:00=10 (maximum of 10 concurrent jobs, 24 hours a day). In this case, because the maximum number of concurrently executable jobs for the default execution agent is 00:00-00:00=5 (maximum of five concurrent jobs, 24 hours a day), a maximum of 15 jobs could be executed concurrently.

When you specify a maximum number of concurrently executable jobs, specify a value appropriate for the execution host.

(2) Checking whether the maximum number of concurrent jobs has been reached when jobs remain in queuing status

When the number of active jobs on an agent host reaches the maximum number of concurrently executable jobs, subsequent jobs might remain in the queuing status for a long time before being executed. To check whether the maximum number of concurrently executable jobs has been reached, execute the ajsagtshow command and compare the number of active jobs (JOB) against the maximum number of concurrently executable jobs (CON-EXE). For details about the ajsagtshow command, see ajsagtshow in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference. Note that you can also perform this operation from JP1/AJS3 - Web Console.

By setting up JP1/AJS3 to output the following message to the integrated trace log when the maximum number of concurrent jobs is reached and no more jobs can be registered for execution, you can check whether this is the reason for execution delays.

KAVU4310-I  The number of executing jobs reaches the
concurrently-executable-job-limit (maximum-number-of-concurrently-executable-jobs) at the agent. (agent-host-name) (host name: host-name, job number: job-number)

For details about how to perform this setting, see the following descriptions:

In Windows:

6.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the JP1/Automatic Job Management System 3 Configuration Guide

In UNIX:

15.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the JP1/Automatic Job Management System 3 Configuration Guide

2.5.5 Considering reduction of job distribution delay

When a job is distributed simultaneously from the manager host to multiple execution agents, if a communication failure has occurred on three or more of those agents, job distribution to the other execution agents might be delayed. When this occurs, the manager host can check the status of communication with each execution agent to suppress job distribution to execution agents on which a communication failure has occurred. As a result, delays in job distribution can be reduced. In JP1/AJS3, this function is called job distribution delay reduction function.

For details about how to enable the job distribution delay reduction function, see 21.5 Setting up the job distribution delay reduction function in the JP1/Automatic Job Management System 3 Configuration Guide.

(1) Overview of the job distribution delay reduction function

If the job distribution delay reduction function is enabled, the manager host manages the status of each execution agent. The following table describes the statuses of execution agents.

Table 2‒42: List of statuses of execution agents

No.

Status

Description

1

Not checked

The status of the execution agent has not been identified yet.

Job distribution to the execution agent is possible.

2

Connectable

The manager host can normally communicate with the execution agent.

Job distribution to the execution agent is possible.

3

Unconnectable

The execution agent cannot receive jobs because a communication failure has occurred.

Job distribution to the execution agent is not possible. (Jobs to be distributed to this execution agent enter the Queuing status on the manager host.)

4

Unavailable

Job distribution to the execution agent is explicitly suppressed by using the ajsagtalt command.

Job distribution to the execution agent is not possible. (Jobs to be distributed to this execution agent enter the Queuing status on the manager host.)

When no communication failures have been detected on any execution hosts, the manager host assumes the status of each execution agent to be Not checked (the default status). The manager host distributes a job to execution agents with the Not checked status.

Upon detecting a failure in communication with an execution agent, the manager host starts monitoring the status of the execution agents. The following describes the status transitions of execution agents:

The manager host checks the communication status of execution agents whose status is Not checked or Connectable and for which jobs are queuing, as well as the communication status of execution agents whose status is Not checked or Connectable and that are connected to a group of execution agents for which jobs are queuing. This is called the communication status check.

The status of the execution agents changes to one of the following according to the result of the communication status check:

Connectable

Unconnectable

The manager host distributes the job to the execution agents for which the status is Connectable, and does not distribute the job to the execution agents for which the status is Unconnectable.

The job distributed to Connectable execution agents is executed on the execution agents. One hour after the status of an execution agent changes to Connectable, the status changes to Not checked.

A job that could not be distributed to an execution agent for which the status is Unconnectable remains queuing, and waits for the communication failure on the execution agent to be corrected. If an execution agent has not recovered when the wait time for error recovery elapses# (in the case of the event job, even if the retransmission of the unreported information is complete), the job status changes to Failed to start.

#

For details about the wait time for error recovery of agents, see 6.2.12 Changing the wait time for recovery when an agent has failed in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows) or see 15.2.12 Changing the wait time for recovery when an agent has failed in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX).

The following figure shows an overview of distributing a job according to the status of execution agents.

Figure 2‒51: Distribution of a job according to the status of execution agents

The manager host periodically polls Unconnectable execution agents to check the connection status. This is called the communication recovery check.

The communication recovery check is repeated until the execution agent recovers from the communication failure.

The status of each execution agent changes to one of the following statuses according to the result of repeated communication recovery checks:

Connectable

When an execution agent recovers from a communication failure, the execution agent's status changes to Connectable, and job distribution starts. If there are no execution agents whose status is Unconnectable, the communication recovery check ends.

Not checked

If an execution agent does not recover from a communication failure within 24 hours (at the default settings), the execution agent's status changes from Unconnectable to Not checked, and the communication recovery check stops.

Supplementary note

If an execution agent group is specified as the job destination, the job is distributed to the execution agents with the highest priority among the Connectable or Not checked execution agents associated with the group.

Even if JP1/AJS3 version 11-10 or earlier is installed on the job-destination agent hosts, the agent hosts are subject to communication status check and communication recovery check.

(2) Jobs subject to job distribution delay reduction

The job distribution delay reduction function can be applied to the following types of jobs:

Unix job (with the exception of queueless jobs)

PC job (with the exception of queueless jobs)

Flexible job

The function only affects the communications between JP1/AJS3 - Manager and the JP1/AJS3 that is working as a relay agent. The function does not affect the communications between JP1/AJS3 and the destination agents.

Event job

Action job (with the exception of queueless jobs)

Custom job

Passing information setting job

HTTP connection job

The function only affects the communications between JP1/AJS3 - Manager and the JP1/AJS3 - Agent hosts that execute HTTP connection jobs. The function does not affect the communications between JP1/AJS3 - Agent and a web server.

(3) Monitoring interval of the job distribution delay reduction function

By using the environment setting parameters for the job distribution delay reduction function, you can set the connection timeout period, the interval at which to perform communication recovery checks, and the amount of time after which communication checks are to stop. The following figure shows the time periods that can be set by using environment setting parameters.

Figure 2‒52: Time periods that can be set by using environment setting parameters

The time required to carry out a communication status check or communication recovery check (connection timeout). This value is specified by using the AGMCONNECTTIMEOUT environment setting parameter. The default is 10 seconds.

The interval at which to perform a communication recovery check. This value is specified by using the AGMINTERVALFORRECOVER environment setting parameter. The default is 180 seconds.

The time before the status of an execution agent changes from Unconnectable to Not checked. This value is specified by using the AGMERRAGTSTATRESETTIME environment setting parameter. The default is 24 hours.

(4) Forcibly terminating a job when the job distribution delay reduction function is used

If the job distribution delay reduction function is used, job distribution is not delayed even when a communication failure occurs during distribution of a forced-termination request for a job. In the same way that jobs are distributed, the request is distributed to the execution agents whose status is Connectable or Not checked. Distribution of the request is suppressed for execution agents whose status is Unconnectable or Unavailable. If the forced-termination request for a job is suppressed, the status of the job changes to Ended abnormally, and the message KAVU4221-E is output to the integrated trace log. Note that user programs executed by the job are not forcibly terminated.

(5) When you want to stop an execution agent for a scheduled purpose

If the job distribution delay reduction function is enabled and you want to stop an execution agent for a scheduled purpose such as maintenance, specify the following settings for the execution agent you want to stop, in order to prevent delays in job distribution to other running execution agents:

Use the ajsagtalt command to change the job transfer restriction status to Hold or Blockade.

Use the ajsagtalt command to change the status of the execution agent to Unavailable.

If you do not change the status of the execution agent to Unavailable, the communication status check reports the status to be Unconnectable. In this case, because the communication recovery check continues for the execution agent that has stopped, recovery detection might be delayed until the status of the execution agent changes to Not checked. To redistribute a job to an execution agent whose status you changed to Unavailable, use the ajsagtalt command to change the status of the execution agent to Not checked.

Note that you can also perform these operations from JP1/AJS3 - Web Console.

(6) Relationship between the job transfer restriction and the job distribution delay reduction function

The following table describes the job status transitions that occur based on the job transfer restriction status and the status of the execution agent according to the job distribution delay reduction function. For details about job transfer restriction, see 5.2 Restricting job transfer in the manual JP1/Automatic Job Management System 3 Overview.

Table 2‒43: Job status transitions that occur when job transfer restriction is used in conjunction with the job distribution delay reduction function

Job transfer restriction status

Execution agent status

Job status transition

Event job status transition

Effective

Not checked

Connectable

Now queuing → Now running → Ended

Now queuing → Now running → Ended

(The transfer of event jobs cannot be restricted.)

Unconnectable

Unavailable

Now queuing → Failed to start

(The status changes to Failed to start after the wait time for the error recovery of agents has elapsed.)

Now queuing → Failed to start

Ineffective

Not checked

Connectable

Immediately Failed to start

(Now queuing jobs have the same status as Effective jobs.)

Now queuing → Now running → Ended

(The transfer of event jobs cannot be restricted.)

Unconnectable

Unavailable

Immediately Failed to start

(The status of Now queuing jobs changes to Failed to start after the wait time for the error recovery of agents has elapsed.)

Now queuing → Failed to start

Hold

Not checked

Connectable

Now queuing

Now queuing → Now running → Ended

(The transfer of event jobs cannot be restricted.)

Unconnectable

Unavailable

Now queuing

Now queuing → Failed to start

Blockade

Not checked

Connectable

Immediately Failed to start

(Now queuing jobs have the same status as Hold jobs.)

Now queuing → Now running → Ended

(The transfer of event jobs cannot be restricted.)

Unconnectable

Unavailable

Immediately Failed to start

(Now queuing jobs have the same status as Hold jobs.)

Now queuing → Failed to start

(7) Note on the job distribution delay reduction function

One hour after the status of an execution agent is determined to be Connectable, the status of the execution agent changes to Not checked. Suppose that a communication failure occurs on three or more execution agents determined to be Connectable before their status changes from Connectable to Not checked. In this case, an attempt to simultaneously distribute jobs to those execution agents might cause a delay in job distribution. If you are going to enable the job distribution delay reduction function, do not stop the agent monitoring process (ajsagtmond). If you stop this process, the following operations are performed:

Jobs are distributed to all execution agents regardless of the agents' status, excluding execution agents whose status is Unavailable.

If jobs are distributed to three or more execution agents for which communication is disabled, the distribution of jobs to normally operating execution agents will be delayed. (This is the same as when the job distribution delay reduction function is disabled.)

While the agent monitoring process is stopped, the detection of the recovery of execution agents for which an error was previously detected will be delayed. (This is the same as when the job distribution delay reduction function is disabled.)

2.5.6 Considering reduction of delays in job status transitions

When the manager host communicates with multiple execution agents, if a communication failure occurs during the response to one or more execution agents, the manager host continuously responds to the execution agents for a maximum of 10 minutes. At this time, job execution might be delayed. For example, the job status might not change for 10 minutes. Due to the impact of the communication failure, a delay of 10 or more minutes might also occur during the status transition of a job executed on an execution agent that is available for normal communication.

In this case, you can suppress response from the manager host to execution agents that cannot respond normally so that the manager host responds to notifications only from normal execution agents. This can reduce delays in job status transitions. This function is called function for reducing job status transition delays.

(1) Overview of the function for reducing job status transition delays

The function for reducing job status transition delays can suppress response to an execution agent on which a communication failure has occurred. This can reduce delays in the status transition of jobs executed on normal execution agents. The following figure shows an example of job status transition when a failure occurs during communication with execution agents.

Figure 2‒53: Job status transition when a communication failure occurs on an execution agent

This function applies to communication shown in the following table.

Table 2‒44:  Communication subject to the function for reducing job status transition delays

Service name

Port number

Purpose

jp1ajs2qman

20241/tcp

To receive job#1 registrations

To receive a job's#1 standard output file and standard error output file

To accept requests for execution of job execution commands#2 other than jp1exec and jp1exit

To link with JP1/NQSEXEC or JP1/OJE for VOS3 (to receive job registrations)

jp1ajs2qnfy

20243/tcp

To receive job#1 start/end notifications from JP1/AJS3 - Agent

jp1ajs2eamgr

20246/tcp

JP1/AJS3 - Manager event job execution

#1

Standard jobs (other than queueless jobs), HTTP connection jobs, action jobs, and custom jobs.

#2

See the table of job execution commands in 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

The function for reducing job status transition delays is disabled by default. To enable the function, set the following two environment setting parameters:

ResponseTimeout

ReduceStateTransitionDelay

For details about how to enable the function for reducing job status transition delays, see 20.8.2 Details of the environment setting parameters for communication control in the JP1/Automatic Job Management System 3 Configuration Guide.

(2) Jobs subject to function for reducing job status transition delays

The function for reducing job status transition delays can be applied to the following types of jobs:

PC job (with the exception of queueless jobs)

Unix job (with the exception of queueless jobs)

Action job (with the exception of queueless jobs)

Submit Job

Queue Job

Custom job

HTTP connection job

Passing information setting job

Flexible Job

Event Job

(3) Interval for monitoring communication with execution agents

If the function for reducing job status transition delays is enabled and a communication failure is detected on an execution agent, the manager host suppresses a response to that execution agent for 5 minutes after the failure is detected. If the communication recovers after 5 minutes have passed, the manager host terminates the suppression of response. If the communication has not recovered, the manager host suppresses response for a further 5 minutes. The following shows the interval for monitoring communication with execution agents.

Figure 2‒54: Interval for monitoring communication with execution agents

The amount of time that can elapse before a communication failure is detected when the manager host responds to a notification from an execution agent. You can change this value in the ResponseTimeout environment setting parameter. The default is 10 seconds.

The amount of time for which the manager host suppresses response to the execution agent. This value is fixed to 5 minutes.

The interval at which the execution agent resends a notification to the manager host. You can specify this value for each job by using an environment setting parameter. The following table shows the applicable jobs and environment setting parameters.

Table 2‒45: Applicable jobs and environment setting parameters

Job

Environment setting parameter

Standard job (with the exception of queueless jobs)

NotfyJobStateInterval

NotfyJobStateCount

HTTP connection job

Action job

Custom job

Event Job

NotificationRetryInterval

NotificationRetryCount

If a response to the execution agent fails and a communication failure is detected, the manager host outputs the KNAC0403-W message to the integrated trace log. The KNAC0403-W message is output for each IP address of the execution agent where a communication failure occurred. If communication with the execution agent recovers, the KNAC0402-I message is output to the integrated trace log. If a communication failure occurs again after communication recovers or after the JP1/AJS3 service stops, the KNAC0403-W message is output again.

(4) Note on the function for reducing job status transition delays

Using the function for reducing job status transition delays might cause a delay in detecting a recovery from communication failure. The following figure shows when a recovery from a communication failure can be detected depending on whether the function for reducing job status transition delays is disabled or enabled.

Figure 2‒55: Time when the recovery of an execution agent from communication failure can be detected

2.6 Determining the JP1/AJS3 database configuration

JP1/AJS3 - Manager uses a relational database to manage data for controlling job execution.

The following table lists JP1/AJS3 functions and the location of the data used by each function.

Table 2‒46: JP1/AJS3 functions and databases

Function

Stored data

Location

Scheduler control

Job execution control

Schedule definition

Execution schedules

Jobnet definitions

Jobnet statuses

Embedded database#

Agent management control

Execution agent information

Embedded database#

Event/action control

Status of received events and executed actions

Standard files

(No database is used.)

Queueless job execution control (queueless agent function)

Executed job information

Standard files

(No database is used.)

Submit job control (execution control of QUEUE jobs and submit jobs)

Queue/agent configuration

Job execution status

ISAM

#

In JP1/AJS3, data can also be stored in an external database provided in a cloud environment, instead of the embedded database.

For details about the external database, see 2.11 Considering use of an external database in a cloud environment.

2.6.1 Types of JP1/AJS3 databases

You can configure different types of databases in a JP1/AJS3 system, depending on how the system is to be used.

For the types of databases supported by JP1/AJS3 and how to set up a database, see 1.4 JP1/AJS3 database configurations in the manual JP1/Automatic Job Management System 3 Overview.

2.6.2 JP1/AJS3 database configuration

The following figure shows the JP1/AJS3 database configuration.

Figure 2‒56: JP1/AJS3 database configuration

The following table lists the types of JP1/AJS3 databases and the information stored in each type.

Table 2‒47: JP1/AJS3 database types and stored information

Database type

Information stored in the database

Scheduler database

Definition information for:

- Jobs and jobnets

- Calendars and schedules

Execution results and execution statuses (jobs and jobnets)

Agent management database

Definition information for:

- Execution agents

- Execution agent groups

Database for QUEUE jobs and submit jobs#

Execution results and execution statuses for:

- Jobs submitted by the jpqjobsub command

- QUEUE jobs requested for execution by a scheduler service

Configuration definition information for agents, queues, and resources that can be locked for exclusive use

#

Use an ISAM database. ISAM is supplied as standard with JP1/Base.

JP1/AJS3 incorporates a range of functions that request job execution (execution of PC jobs, Unix jobs, and QUEUE jobs). These functions include scheduler services, and commands such as the jpqjobsub command for controlling submit job execution.

For jobs executed from a scheduler service, the jobnet definition information, execution statuses, and execution results are managed in a scheduler database. To execute a job in a jobnet (PC job, Unix job, or QUEUE job), the scheduler service sends a job execution request to the job execution control. The job's execution status and result are managed in the scheduler database (for QUEUE jobs, the job status and execution result are also managed in the database for QUEUE jobs and submit jobs). The scheduler database is updated when the job's status changes.

When the jpqjobsub command is used to request job execution, the request is sent directly to the submit job control without going through a scheduler service. The job's execution status and result, together with configuration definition information about the agent, queue, and execution-locked resources, are managed in the database for QUEUE jobs and submit jobs. For details about this database, see 7.1.3 Database for QUEUE jobs and submit jobs.

2.6.3 JP1/AJS3 database tables

This subsection describes the databases used by the scheduler control, job execution control, and agent management control.

For details about the database for QUEUE jobs and submit jobs used by the submit job execution control, see 7.1.3 Database for QUEUE jobs and submit jobs.

(1) Scheduler database

The following table describes the information stored in the scheduler database used by the scheduler control and job execution control.

Table 2‒48: Tables in a scheduler database

Table name#1

Contents

Row length#2

(bytes)

Variable-length rows#2

(bytes)

Number of indexes

Index length#2

(bytes)

Definition table

AJSUNIT

Unit management

408

(640)#3

None

2

Primary keys: 4

Sub-keys: 36

AJSARROW

Unit relationship definition

52

None

1

12

AJSBODY

Unit definition

1,024

4 to 64,000

1

4

AJSSCH

Schedule definition

148

(208)#3

4 to 8,192

1

8

AJSCAL

Calendar definition

1,540

None

1

8

AJSRELS

Release definition

1,180

None

3

Primary keys: 36

Sub-keys: 8

Sub-keys: 8

Execution table

AJSSTAT

Unit status

1,540

(1,720)#3

None

1

12

AJSENTRY

Registration for execution

764

None

1

8

AJSGEN

Generation management

124

4 to 32,000#4,

4 to 64,000#4

1

8

AJSPERF

Statistics

120

None

2

Primary keys: 4

Sub-keys: 8

AJSID

ID management

76

None

1

8

AJSJINF#5

Job information

320

1 to 15,728,640

1

16

Management table

AJSDBOWNER#6

Database management

28

None

1

4

#1

Default names in the JP1/AJS3 environment settings. If the database in use is an external database, AJS in table names changes to AJS1.

For an embedded database or an external database, the index has a table name followed by INDEX1 for the primary key (including tables with no sub-keys), and INDEX2 and INDEX3 for the sub-keys.

#2

The row length given for a variable-length table is the size of the fixed-length portion at the beginning of each record. If the database in use is an external database, the row length might become shorter than the value shown in the table, depending on the data.

Note that in addition to this size, the table region on the disk includes a management area and therefore does not match the table size given above.

For an embedded database, a JP1/AJS3 database has a maximum variable-row length of 64,000 bytes, and contains one field for data plus another variable-length field. The variable-length field (maximum 64,000 bytes) has two VARCHAR fields. If the variable-length data to be stored in one of the two fields does not exceed 32,000 bytes, zero-length data (SQLLEN = 1) is set in the second VARCHAR field.

#3

The value enclosed in parentheses is used when the scheduler database has been set up by using the ajsembdbsetup command with the -e sjis option specified. For details, see ajsembdbsetup in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

#4

Two variable-length areas are defined in the generation management table.

#5

This table exists only when the backup enhancement function is enabled in JP1/AJS3 - Manager or when an external database is used.

#6

This table exists only when JP1/AJS3 - Manager uses an external database.

The following describes the number of records in each table and how the variable-length records are used.

The tables for the scheduler database can be divided into definition tables, which store unit definitions, execution tables, which store execution schedules and results of jobnets and jobs, and management tables, which are used to manage the database.

(a) Definition tables

The following describes the record count and variable-length records for each type of definition table.

Unit management table (AJSUNIT)

The number of records is the number of JP1/AJS3 units (total number of job groups, jobnets, and jobs).

Unit relationship definition table (AJSARROW)

The number of records is the number of relationships established among jobnets.

Unit definition table (AJSBODY)

The number of records is the total number of job definitions and jobnet definitions.

Except for schedule information and calendar information, unit definition information including command statements and script file names is stored.

Schedule definition table (AJSSCH)

Multiple information items are stored in the schedule definition.

The number of stored records is equivalent to the number of records containing the following information:

Schedule information

The number of records is the total number of jobnets plus the total number of scheduling rules defined for them. The table stores the common schedule information and scheduling rule information.

The common schedule information (names of units referencing the calendar) and scheduling rule information (scheduling rules) are stored as variable-length data in the same format as the parameters in the unit definition file.

Jobnet connector information

The number of records is equivalent to the number of jobnet connectors plus the number of connection-destination jobnets. The full path name of the connection-destination jobnets, the connection-destination host names, and the connection-destination scheduler service names are saved as variable-length data.

Wait information

The number of records is equivalent to the total number of units with wait conditions plus the total number of wait conditions set for all units. Both common wait information and information about units targeted for waiting are saved.

For the information about units targeted for waiting, the unit complete names of the units targeted for waiting are saved as variable-length data in the same format as the parameters in the unit definition file.

Calendar definition table (AJSCAL)

The number of records is the number of job groups plus the number of years defined in the calendar.

Release definition table (AJSRELS)

The number of records is the number of jobnets registered for release plus the number of times each jobnet has been registered for release. As JP1/AJS3 automatically deletes these records depending on the status of the jobnet registered for release, the number of records might be different from the calculated figure.

(b) Execution tables

The following describes the record count and variable-length records for each execution table.

Unit status table (AJSSTAT)

The number of records necessary for each registered root jobnet is root-jobnet-and-total-number-of-nested-jobnets-and-jobs x (number-of-logs-to-keep + number-of-scheduled-generations-registered-for-fixed-execution + 1), where the number of logs to keep includes sub-generations created when start conditions are satisfied.

Calculations are made for all registered root jobnets, and the sum becomes the total number of records.

Registration for execution table (AJSENTRY)

The number of records necessary for each registered root jobnet is number-of-logs-to-keep-for-the-root-jobnet + number-of-scheduled-generations-registered-for-fixed-execution, where the number of logs to keep includes sub-generations created when start conditions are satisfied. Calculations are made for all registered root jobnets, and the sum + 1 becomes the total number of records.

Generation management table (AJSGEN)

The number of records and amount of information stored as variable-length data differs depending on whether start conditions are used for the registered root jobnets and whether wait conditions are used.

For a root jobnet without a start condition, an item of information with a length of ((number-of-logs-to-keep + number-of-scheduled-generations-registered-for-fixed-execution) + 1) x 8 bytes is stored as variable-length data (4 to 64,000).

number-of-release-IDs-release-registered-for-root-jobnets x 4 bytes of information is stored as variable-length data (4 to 32,000).

In the same way, for a root jobnet that has a start condition, an item of data with a length of ((number-of-logs-to-keep + number-of-scheduled-generations-registered-for-fixed-execution) + 1) x 8 bytes is stored as variable-length data. In addition, information about the number of sub-generations, calculated as number-of-sub-generations-created-every-time-a-start-condition-is-satisfied x 8 bytes is stored as variable-length data (4 to 64,000).

If a unit with wait conditions is already registered, records equivalent to number-of-registered-units-with-wait-conditions x number-of-logs-to-keep are added. For each record, information equivalent to number-of-set-wait-conditions x 56 bytes is stored as variable-length data (4 to 32,000).

Calculate the number of records for all the registered root jobnets and all the registered units with wait conditions. The total is the total number of records.

Statistics table (AJSPERF)

The number of records is the total number of units registered for execution.

ID management table (AJSID)

The number of records is the number of records in all the active units.

Job information (AJSJINF)

The number of records is calculated from the following expression: Number-of-logs-to-keep x (number-of-all-jobs-subordinate-to-the-root-jobnet-(including-event-jobs) x 2 + number-of-all-event-jobs-subordinate-to-the-root-jobnet)

(c) Management tables

The following describes the number of records in management tables.

Database management (AJSDBOWNER)

The number of records is 1.

(d) Supplementary notes about the scheduler database

If the scheduler service does not stop as planned due to a power failure or other reason, processing resumes when the service next starts, and the KAVS0211-W message is output to the Windows event log or syslog. Check the job status as jobs might have stopped before completion.

(2) Agent management database

The agent management database is used by the agent management control. This database manages definition information about execution agents and execution agent groups. The following table describes the database tables in an agent management database.

Table 2‒49: Tables in an agent management database

Table name

Contents

Row length

(bytes)

Variable-length rows

(bytes)

Number of keys

Number of indexes

Index length (bytes)

AJSEXECAGT

Execution agent definition

952

None

1

1

4

AJSAGTEXECCNT

Maximum concurrent jobs definition

20

None

1

1

8

AJSEXECAGTGRP

Execution agent group definition

696

None

1

1

4

AJSLINKAGT

Connected execution agents definition

20

None

1

1

8

AJSAGTDBOWNER#

Database management

28

None

1

1

4

#

This table exists only if the database in use is an external database.

The number of records in each table is as follows:

Execution agent definition (AJSEXECAGT)

The number of records is the number of defined execution agents.

Maximum concurrent jobs definition (AJSAGTEXECCNT)

The number of records is number-of-defined-target-agents x 48.

Execution agent group definition (AJSEXECAGTGRP)

The number of records is the number of defined execution agent groups.

Connected execution agents definition (AJSLINKAGT)

The number of records is the total number of execution agents connected to each execution agent group.

Database management (AJSAQGTDBOWNER)

The number of records is 1.

2.6.4 Scale of the database to be used in JP1/AJS3

The scale of the database required for JP1/AJS3 operation varies depending on operational conditions such as the number of units to be executed in a day. Consider how JP1/AJS3 is to be used, and estimate the required scale of the embedded database.

For details about how to estimate the database area, see 23.2 Estimating the database area in the JP1/Automatic Job Management System 3 Configuration Guide.

2.6.5 Database settings that are set up in JP1/AJS3

An embedded database environment is configured when you set it up during a new installation of JP1/AJS3 - Manager or when you execute a setup command after installation.

The following table provides an overview of embedded databases that are created during the extended setup process.

Table 2‒50: Overview of embedded databases that are created during the extended setup process

Settings

When a new installation is performed

When the jajs_setup command is executed

When the jajs_setup_cluster command is executed

When the jajs_migrate command is executed

Database model

Small-scale#1

Small-scale#1

Small-scale#1

Small-scale#1

Embedded database practical directory

Windows:

JP1/AJS3-installation-folder\embdb\_JF0

UNIX:

/opt/jp1ajs2/embdb/_JF0

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier

UNIX:

/opt/jp1ajs2/embdb/setup-identifier

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier

UNIX:

/opt/jp1ajs2/embdb/setup-identifier

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier

UNIX:

/opt/jp1ajs2/embdb/setup-identifier

Data area storage directory

Windows:

JP1/AJS3-installation-folder\embdb\_JF0\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/_JF0/dbarea

Physical host environment

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

Logical host environment

Windows:

folder-specified-in-the-D-option\jp1ajs2\embdb\setup-identifier\dbarea

UNIX:

directory-specified-in-the-D-option/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

folder-specified-in-the-d-option\jp1ajs2\embdb\setup-identifier\dbarea

UNIX:

directory-specified-in-the-d-option/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

System file area storage directory

Windows:

JP1/AJS3-installation-folder\embdb\_JF0\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/_JF0/dbarea

Physical host environment

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

Logical host environment

Windows:

folder-specified-in-the-D-option\jp1ajs2\embdb\setup-identifier\dbarea

UNIX:

directory-specified-in-the-D-option/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

foder-specified-in-the-d-option\jp1ajs2\embdb\setup-identifier\dbarea

UNIX:

directory-specified-in-the-d-option/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

Work area directory

Windows:

JP1/AJS3-installation-folder\embdb\_JF0\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/_JF0/dbarea

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

Physical host environment

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

Logical host environment

/opt/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/opt/jp1ajs2/embdb/setup-identifier/dbarea

Windows:

JP1/AJS3-installation-folder\embdb\setup-identifier\dbarea

UNIX:

/var/opt/jp1ajs2/embdb/setup-identifier/dbarea

Setup identifier

_JF0

_JF0-_JFZ#2, #3

The value of the -I option

_JF0-_JFZ#2

Port number

22220

22220-22239#2, #4

The value of the -P option

22220-22239#2

Database area auto-increment

Enabled#7

Enabled#7

Enabled#7

Enabled

System log auto-increment

Enabled#7

Enabled#7

Enabled#7

Enabled

Automatic log unload functionality

Disabled

Disabled

Disabled

Disabled

Duplication of system logs

Disabled

Disabled

Disabled

Disabled

Reuse start points for the reuse free space functionality

Small-scale#1

Small-scale#1

Small-scale#1

Small-scale#1

Backup enhancement function#5

Disabled

Disabled#6

Disabled#6

Disabled

#1

For a new installation, the database is configured by using the database model specified during installation.

When the -M option of the jajs_setup and jajs_setup_cluster commands or the -s option of the jajs_migrate command is specified, the database is configured with the database model specified by the option.

#2

A value in this range is automatically assigned.

#3

When you add a scheduler service and specify the setup identifier of a configured embedded database in the -I option, a scheduler service database is created in the embedded database configured with the specified setup identifier. If a setup identifier that has not been configured is specified in the -I option, a new embedded database is configured and the scheduler service database is created.

#4

If you specify the -P option, the value specified in the -P option will be set.

#5

To use the backup enhancement function, you must specify this function when you set up the embedded database. For details about the backup enhancement function, see 5.2.5 Backing up and recovering an embedded database by using the backup enhancement function.

#6

The database is configured as specified by the -B option.

#7

If a large-scale database model is specified, it will become disabled.

If you configure an embedded database environment during a new installation, you can only specify the database model. For details about how to do this, see 2.2.3(1) New installation in the JP1/Automatic Job Management System 3 Configuration Guide.

If you skip configuring an embedded database environment during a new installation or if you specify the -S option in the jajs_migrate, jajs_setup, or jajs_setup_cluster command, an embedded database environment is not configured. In this case, see the description of the setup in 23.4 Advanced setup of an embedded database in the JP1/Automatic Job Management System 3 Configuration Guide or 23.5 Advanced setup for the embedded database (in a cluster configuration) in the JP1/Automatic Job Management System 3 Configuration Guide, and then configure an embedded database environment.

If you want to configure an embedded database by using different settings from those in Table 2-50, perform setup as described in the following sections, and then configure an embedded database environment: 23.4 Advanced setup of an embedded database in the JP1/Automatic Job Management System 3 Configuration Guide or 23.5 Advanced setup for the embedded database (in a cluster configuration) in the JP1/Automatic Job Management System 3 Configuration Guide.

If you want to change the settings of an embedded database that has been configured, you need to set up the embedded database environment again. For details, see 23.4.1(6) Setting up an embedded database again in the JP1/Automatic Job Management System 3 Configuration Guide.

2.7 JP1/AJS3 security considerations

This section describes security measures for the safe use of JP1/AJS3.

As security measures, we recommend that you use firewalls and JP1/AJS3 functions that prevent access from unauthorized users and prevent the execution of jobs from unintended hosts.

The figure and table below show an example of measures taken to prevent access by unauthorized users. The numbers in the figure correspond to the numbers in the table.

Figure 2‒57: Measures preventing access by unauthorized users

Table 2‒51: Measures preventing access by unauthorized users

No

Operation from unauthorized user

Protective measure

Description

1

Access from outside the company

Firewall

Placing a firewall prevents access from unauthorized users.

For details about the firewall, see 2.3.2 Firewall and communication basics.

2

Placement of DMZ

By placing the Web Console server in the DMZ, users can access the JP1/AJS3 system safely from a LAN outside the company.

3

Eavesdropping on communication data

Encryption of communication paths

Messages are encrypted by using technologies such as VPN and SSL. The Web GUI also supports HTTPS communication.

For details about communication encryption with SSL, see 2.3.6 Encryption of JP1/AJS3 communications with SSL.

4

Login from inside the company

Restrictions on physical access to machines

Consider the locations of the machines to restrict physical accesses.

5

Proper management of OS users

Manage OS user accounts properly so that general users without administrator permissions are not permitted to log in to manager hosts.

Do not assign OS users permissions other than those necessary for executing a job.

6

Proper management of JP1 users

Manage JP1 user accounts properly.

In particular, change the initial password for the JP1 user jp1admin. Add JP1 users only when necessary, and set appropriate permissions for each JP1 user.

7

Connection source restrictions in JP1/AJS3

Use a JP1/AJS3 function to limit the hosts that can access manager hosts or agent hosts. For details, see 2.3.9 Restricting hosts that can access JP1/AJS3.

8

Proper management of embedded database administrators

Manage accounts for embedded database administrators properly and change the passwords for them. For details about how to do this, see B. Notes on Using the Embedded-Database Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

9

Unauthorized use of the JP1/AJS3 - View login history

Preventing the login history from being displayed

Using a JP1/AJS3 function, you can prevent the previously used JP1 login user names and the names of previously connected hosts from appearing on the Login screen of JP1/AJS3 - View. By hiding previously used login information, you can prevent unauthorized users from logging in to the system by using valid JP1 user names. For details, see 11.2.6 Preventing the history of previously used login user and connected host names from appearing on the Login screen in the JP1/Automatic Job Management System 3 Operator's Guide.

We recommend that you disable the predictive conversion functionality of character input software such as IMEs. If this functionality is enabled, suggestions might be displayed when a user is inputting information in User name, Password, or Host to connect, even though previously used login information is set to be hidden.

2.8 Replicating a Virtual Machine on which JP1/AJS3 Is Installed and Set Up

After you have installed and set up JP1/AJS3 - Manager and JP1/AJS3 - Agent on a virtual machine, you can replicate that virtual machine. This reduces the workload for installing and setting up JP1/AJS3 instances running on multiple virtual machines.

If you want to replicate the default settings immediately after installing JP1/AJS3 products, replicate the virtual machine after installation. If you want to replicate the environment in which environment setting parameters and system environments have been set up, replicate the virtual machine after the setup.

By replicating a virtual machine, you only have to install and set up JP1/AJS3 for a single virtual machine to operate JP1/AJS3 on multiple virtual machines. You can also prevent omissions or differences in the settings among multiple virtual machines. Thus, the more virtual machines there are, the more effectively replication of a virtual machine can reduce working hours. The following figure shows the relationship between the number of virtual machines and working hours.

Figure 2‒58: Relationship between the number of virtual machines and working hours

For details about replicating a virtual machine after JP1/AJS3 is installed and configured, see 22. Replicating a Virtual Machine on which JP1/AJS3 Is Installed and Set Up in the JP1/Automatic Job Management System 3 Configuration Guide.

2.8.1 Operation example for replicating a virtual machine on which JP1/AJS3 - Manager is set up

The following figure shows an operation example for replicating a virtual machine on which JP1/AJS3 - Manager has been set up.

Figure 2‒59: Operation example for replicating a virtual machine on which JP1/AJS3 - Manager has been set up

This example shows how a virtual machine environment set up for branch office A is replicated to other branch offices. In this example, a template means the original virtual machine.

The following describes the general procedure for this example:

Install JP1/AJS3 - Manager on a virtual machine in branch office A.

On the virtual machine for branch office A, set up the common environment settings for the branch offices.

Create a template based on the virtual machine for branch office A.

Replicate the template as virtual machines for branch offices B, C, and D.

On the virtual machine for each branch office, specify settings for each respective branch office.

2.8.2 Notes on replicating a virtual machine on which JP1/AJS3 is installed and set up

Only Windows and Linux support replication of a virtual machine on which JP1/AJS3 has been installed and set up.

Replication of JP1/AJS3 is not supported for a virtual machine for which a logical host has been set up. A logical host must be set up on a replicated virtual machine.

On the original virtual machine, do not install a product that does not support replication of a virtual machine.

For virtual machines on which jobnets have been scheduled and registered for execution in JP1/AJS3, the replication of the virtual machine is unsupported while any of the following types of jobnets exist:

Jobnets of generations whose statuses are not end statuses

Jobnets of scheduled generations that are to be executed next

If jobnets are already scheduled and registered for execution, perform a cold start and delete the scheduling information of jobs on the virtual machine that is to be replicated before replicating the virtual machine.

If jobnets are to be executed for purposes such as post-setup tests, immediately execute the jobnet. Replicate the virtual machine after the status of the jobnet changes to an end status.

2.9 Executing jobs in a cloud environment

This section describes a system configuration that uses a flexible job and the components of such a system.

A flexible job can be executed on execution agents that are not directly managed by the manager host. For example, a flexible job can be executed on execution agents in an auto-scaling cloud environment. An execution agent that executes a flexible job on a cloud is called a destination agent.

Figure 2‒60: Executing a job by using destination agents on a cloud

A job defined in an on-premise environment can be executed in a cloud environment by relaying a flexible job execution request via an agent host. An agent that relays the job execution request is called the relay agent.

The following figure shows an example of combining an on-premise environment and a cloud environment.

Figure 2‒61: Example of combining an on-premise environment and a cloud environment 1

Figure 2‒62:  Example of combining an on-premise environment and a cloud environment 2

In a cloud environment, a flexible job can be distributed to specific execution agents by using a load balancer, or it can be executed by all execution agents in the cloud.

The following figure shows a system configuration that includes a load balancer and a relay agent. For details about the system configuration for executing the same job on all execution agents in an auto-scaling environment, see 2.10 Considerations for executing a job by broadcast execution.

Figure 2‒63: Example system configuration that includes a load balancer and a relay agent

Supplementary notes

If a load balancer is used, it is assumed that the load balancer can distribute TCP packets.

You can use only a load balancer or relay agent. However, if you do not use neither load balancer nor relay agent, we recommend that you use a PC job or a Unix job, not a flexible job.

For details about working through a firewall, see 2.3.2 Firewall and communication basics.

If you execute a job defined in an on-premise environment on a public cloud environment, connect the relay agent and cloud environment with VPN.

For communications between the relay agent and the cloud environment, use a communication environment in which safety and stability is ensured. For details, see 2.3.7 Communications used in a WAN.

The relaying function of a flexible job is executed as a job on a relay agent. Therefore, if a relay agent and an execution agent for other jobs is the same, execution of a flexible job might affect execution of other jobs, for example in terms of the number of concurrently executable jobs. Consider deploying the relay agent for a flexible job separately from execution agents for other jobs.

For cautionary notes on flexible jobs, see 7.8 Notes on using flexible jobs in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

2.10 Considerations for executing a job by broadcast execution

If you want a job to be executed by multiple execution agents at the same time, use a function called broadcast execution. This section describes the system configuration and system components required to execute a flexible job by broadcast execution. For details about the system components, such as relay and destination agents, and other considerations required to execute flexible jobs, see 2.9 Executing jobs in a cloud environment.

The broadcast execution function sends a job defined on the manager host to a broadcast agent. The broadcast agent manages destination agents, and distributes a job to all of the destination agents. A maximum of 100 destination agents can be managed.

The following figure shows an example in which a broadcast agent distributes a job to multiple destination agents.

Figure 2‒64: Example in which a broadcast agent distributes a job to multiple destination agents

The broadcast agent manages the destination agents in the following way:

During setup of the destination agents, the user specifies the broadcast agent that will manage the destination agents.

The destination agents periodically send a heartbeat to the broadcast agent to notify the broadcast agent that they are alive (running).

Upon receiving a heartbeat, the broadcast agent responds to the destination agents.

The broadcast agent manages the destination agents.

The following figure shows an example in which a broadcast agent manages destination agents.

Figure 2‒65: Example in which a broadcast agent manages destination agents

The following figure shows an example of a system configuration that uses a broadcast agent.

Figure 2‒66: Example of a system configuration that uses a broadcast agent

Note that the broadcast agent must be a host that meets the following conditions:

A host that has a static IP address

A host that is not scaled in or out

Supplementary notes

Flexible jobs that are set to be executed by broadcast execution can be used with version 11-10 or later of JP1/AJS3 - Manager, JP1/AJS3 - Agent, and JP1/AJS3 - View.

A relay agent, a broadcast agent, and a destination agent can be installed on the same host. However, if you want to use some of the agents in a cloud environment, we recommend that you install them on separate hosts.

For details about working through a firewall, see 2.3.2 Firewall and communication basics.

For notes on using broadcast execution for flexible jobs, see 7.8 Notes on using flexible jobs in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

2.11 Considering use of an external database in a cloud environment

For a manager host that operates in a cloud environment, an external database provided by a cloud service can be used. Using the external database can alleviate the burden on the system performing everyday operations.

2.11.1 Considering use of an external database

This subsection describes the points that you must consider if you want to operate a manager host in a cloud environment in which an external database is used for the manager host.

The following figure shows an example of a database configuration in which an external database is used.

Figure 2‒67: Database configuration in which an external database is used

(1) Advantages and disadvantages of an external database

An external database has both advantages and disadvantages. Determine whether to use an external database considering how the advantages and disadvantages will affect the purpose of your operations.

Advantages of using an external database

The following shows the probable advantages of using an external database. If reduction of the workload in daily operations is important in your environment, use of an external database might be a better choice.

You can use functionality of the external database provided as a cloud service to automatically back up job definitions, execution results, execution statuses and other information during operation.

If a failure occurs in the external database, you can use functionality of the external database to recover the database to any point in time prior to the failure#. For this reason, you can quickly restart operation of JP1/AJS3 jobs by using recovered information such as the execution statuses and execution results of jobs.

If a failure occurs in a manager host, by recovering a manager host environment that was backed up, you can quickly restart operation of JP1/AJS3 jobs by using recovered information such as the execution statuses and execution results of jobs.

#

For details, see the documentation for the cloud service.

Disadvantages of using an external database

The following shows disadvantages that you will probably encounter when using an external database. If you are building a mission-critical system, use of the embedded database might be a better choice.

The user is responsible for the set-up and operation of an external database. With respect to the investigation of the cause of failure in the cloud service or in the DBMS product, if a failure occurs during operation, the user will need to take actions such as making inquiries to the parties managing the cloud.

Because the external database is accessed via a network, performance in operations such as job execution and command execution is lower for the external database than for the embedded database.

Some JP1/AJS3 functions become unavailable. For details about the functions that become unavailable, see (7) Functions that cannot be used in an environment in which an external database is used.

(2) DBMS product that can be used

The following shows the DBMS product that JP1/AJS3 can use for an external database.

Microsoft SQL Server

For details about the cloud services supported by this product, see the Release Notes.

Note that ODBC is used for connection with the external database. The following figure shows an overview of ODBC-based connection with the external database.

Figure 2‒68: ODBC-based connection to the external database

Cautionary note

To use ODBC, you must install the ODBC driver on the manager host.

(3) Conditions for using an external database and the basic configuration in which an external database is used

This subsection describes the conditions for using the external database and the configuration of the manager host and external database.

(a) Conditions for using an external database

An external database can be used if all of the following conditions are met:

The OS of the manager host that is to be connected with the external database is Windows or Linux.

The manager host is operating in a cloud environment.

The manager host is operating on only a physical host.

The database is in the standard configuration without ISAM.

(b) Restrictions on using an external database

To use SQL Server or another DBMS product that can produce multiple instances of an external database, the following restrictions are placed on the database and its instances:

The databases of the external database used for JP1/AJS3 must contain the data related to JP1/AJS3 only.

Prepare one database for each scheduler service.

The following figure shows an example of database and scheduler service configurations that are supported and not supported.

Figure 2‒69: Database and scheduler service configurations

If multiple scheduler services are used on one manager host, all of the scheduler services must use the external database.

It is impossible to use both the embedded database and an external database for each scheduler service. The following shows an example of configurations of a manager host connected with external databases.

Figure 2‒70: Example of configurations of a manager host connected with external databases

(c) Basic configuration of external databases and a manager host

External databases can be used in either of the following configurations:

Configuration in which one manager host uses multiple instances of the external database

Configuration in which multiple manager hosts use one instance of the external database

The following figure shows configurations in which manager hosts use instances of the external database.

Figure 2‒71: Configuration in which one manager host uses one instance of the external database

Figure 2‒72: Configuration in which one manager host uses different instances of the external database

Figure 2‒73: Configuration in which different manager hosts use one instance of the external database

(d) Version compatibility between a manager host that uses an external database, and other products

The version compatibility between JP1/AJS3 - Manager when an external database is used as its database, and other products (other JP1/AJS3 products, the prerequisite product JP1/Base, and optional products) is the same as the version compatibility when an embedded database is used, with the exclusion of the special notes. For details about version compatibility for each product, see 8.1 Version compatibility.

(4) Connection relationship between the external database and JP1/AJS3 - Manager

The external database and JP1/AJS3 - Manager have the following connection relationship:

The scheduler database configured with the external database can be connected from only the scheduler service that is associated with the scheduler database. That scheduler database cannot be connected from different scheduler services.

The following figure shows the connection relationship between the scheduler database and scheduler services.

Figure 2‒74: Connection relationship between the scheduler database configured with the external database and scheduler services

The agent management database configured with the external database can be connected from only the manager host on which execution agent information is set up. That agent management database cannot be connected from different scheduler services.

The following figure shows the connection relationship between the agent management database and the manager host.

Figure 2‒75: Connection relationship between the agent management database and the manager host

If the external database is recovered or if the manager host operating in a cloud environment is recovered, the connections that were previously set must be set again. The following figures show examples of setting connections again when the external database is recovered and when the manager host operating in a cloud environment is recovered.

Figure 2‒76: Example of setting connections again when the manager host is recovered

Figure 2‒77: Example of setting connections again when the external database is recovered

Use the jajs_extdb command to set the connections again. For details about the jajs_extdb command, see jajs_extdb in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

For details about how to recover the manager host in a cloud environment and how to recover the external database, see 12.2 Recovery from a failure in an environment that uses an external database in the JP1/Automatic Job Management System 3 Administration Guide.

(5) Setting up a manager host that connects to an external database

When you perform a new installation of JP1/AJS3, you can specify whether to automatically set up a scheduler service and embedded database. To use an external database, do not set up a scheduler service and embedded database during the new installation. After the new installation has finished, set up the external database. For details, see 24.2 Setting up JP1/AJS3 to use an external database in the JP1/Automatic Job Management System 3 Configuration Guide.

If JP1/AJS3 is already operating with the embedded database, you can switch the embedded database to the external database by exporting the data to the external database. You can export the following types of data:

Unit definition

Calendar definition

Schedule definition

Execution agent information

Registered execution-schedule information for the root jobnets that are registered for planned execution or fixed execution

For details about how to export data from the embedded database to the external database, see 24.3 Exporting data from the embedded database currently in use to the external database in the JP1/Automatic Job Management System 3 Configuration Guide.

(6) Operation using an external database

While JP1/AJS3 is operating with an external database, job information, jobnet information, and other information that is required for continuation of operation is stored in the external database. Therefore, if the data in the external database has been backed up, operation can be quickly restored when a failure occurs in the external database.

Also, if the same environment as the manager host environment has been prepared and the manager host fails, operation can be quickly restored by using the environment in which the failure has not occurred.

For details about how to restore operation that uses the external database, see 12.2 Recovery from a failure in an environment that uses an external database in the JP1/Automatic Job Management System 3 Administration Guide.

If operation is restored in an environment that uses an external database, the JP1/AJS3 service and the scheduler service perform a disaster recovery start. At this time, the statuses of jobs and jobnets change because of the disaster recovery start. Therefore, confirm safety, and then rerun the jobs and jobnets.

For details about the status of each job and jobnet when disaster recovery start is performed, see 6.2.1 Temporarily changing the start mode of JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

(7) Functions that cannot be used in an environment in which an external database is used

The following shows the functions that cannot be used in an environment in which an external database is used:

Operation that uses logical hosts

Functions that cannot be used in the standard configuration without ISAM

For details about the functions that cannot be used in the standard configuration without ISAM, see A Functions that Cannot Be Used in the Standard Configuration Without ISAM in the manual JP1/Automatic Job Management System 3 Overview.

Running queueless jobs and the queueless agent function

Running a remote jobnet as the transfer-source or transfer destination host

Monitoring operation by using JP1/AJS3 Console

Running commands related to the embedded database (commands whose names begin with ajsembdb)

(8) Notes on using an external database

Note the following points when you use JP1/AJS3 that is operating with an external database:

JP1/AJS3 - Manager does not control start and termination of the external database. Therefore, you must start all necessary instances of the external database before starting operation of JP1/AJS3 - Manager.

If no instances of the external database are running, the JP1/AJS3 service and scheduler services do not start.

For the following files, the maximum file size is limited to 15 MB on the basis of the character encoding used on the manager host that uses the external database:

Standard output files and standard error output files in the job error information directory, stored on the manager host, for standard jobs and HTTP connection jobs (No action is required because the error information is stored in the internal log.)

Execution result details of standard jobs, action jobs, event jobs, and HTTP connection jobs

Operation of JP1/AJS3 might stop because of errors such as communication failures. If an error occurs, restart the scheduler service by performing a hot start, and then resume operation. This will cause the execution of jobs to stop for a period that ranges from several minutes to tens of minutes.

After the restart, the scheduler service is resumed from its state prior to when the scheduler service was ended. In addition, the scheduler service automatically obtains information about jobs whose statuses are Now running from the server where those jobs are to be executed and, where possible, changes the status of those jobs to their actual status. If the scheduler service is able to obtain the actual status of a job, the scheduler service automatically continues execution of the job according to the jobnet definition. If the scheduler service is unable to obtain information from the server where a job is to be executed, the status of the job changes to Ended abnormally. For jobs that end abnormally, check the status of the job and manually execute the job again.

If the temporary change operation management function is used, the maximum amount of information about temporary change operations that can be stored for each root jobnet is 15 megabytes. Make sure the amount of temporary change information estimated by using the following formula does not exceed 15 megabytes.

0.002 x A + 0.003 x B (units: megabytes)

A: The number of the operations performed on the root jobnet and its lower units that are to be saved as temporary change information

B: The number of operations in A that are performed to add execution schedules by specifying passing information

For details about the operations that are saved as temporary change information and the expiration date of temporary change information, see 4.5.16(1) Displaying temporary change information in the JP1/Automatic Job Management System 3 Overview.

2.11.2 Database tables for using an external database

For details about the database tables used for scheduler control, job execution control, and agent management control of JP1/AJS3 when the external database is used, see 2.6.3 JP1/AJS3 database tables.

2.12 Considering installing JP1/AJS3 - Agent in containers

If you install JP1/AJS3 - Agent in containers, you can run business applications or commands on the containers.

2.12.1 Considering the system configuration to be used if JP1/AJS3 - Agent is installed in containers

This section describes the JP1/AJS3 system configuration in a container environment.

A JP1/AJS3 system in which JP1/AJS3 - Agent is installed in containers can have one of the following three configurations:

JP1/AJS3 - Manager is installed on a container host machine and JP1/AJS3 - Agent is installed in each container.

A manager host is prepared, and JP1/AJS3 - Agent is installed both on a container host machine and in each container.

A manager host is prepared, and JP1/AJS3 - Agent is installed in only each container on a container host machine.

The following figures show examples of the preceding system configurations.

Figure 2‒78: JP1/AJS3 system configuration in a container environment (1): JP1/AJS3 - Manager is installed on a container host machine and JP1/AJS3 - Agent is installed in each container

Figure 2‒79: JP1/AJS3 system configuration in a container environment (2): JP1/AJS3 - Agent is installed both on a container host machine and in each container, with a manager host prepared

Figure 2‒80: JP1/AJS3 system configuration in a container environment (3): JP1/AJS3 - Agent is installed in only each container on a container host machine, with a manager host prepared

For details about the setup procedure for installing JP1/AJS3 - Agent in a container, see 21.8 Settings for installing JP1/AJS3 - Agent in containers in the JP1/Automatic Job Management System 3 Configuration Guide.

2.12.2 Prerequisites, restrictions, and estimation of required system resources for installing JP1/AJS3 - Agent in containers

This section shows the prerequisites and restrictions that apply when installing JP1/AJS3 - Agent in containers and describes how to estimate the system resources required for the installation.

(1) Prerequisites for installing JP1/AJS3 - Agent in containers

(a) Supported OSs

For the requirements for the container host machine used when JP1/AJS3 - Agent is installed in a container and the OSs supported within the containers, see the Release Notes.

(b) Supported container management software

The following software products can manage containers in which JP1/AJS3 - Agent can be installed:

Docker

Podman

(c) Network environment

If a container in which JP1/AJS3 - Agent is installed needs to link with a host other than the container host machine, make sure that TCP/IP communication can be performed between the container and host in both directions. For details about the setup procedure for a container to communicate with a host other than the host machine via TCP/IP communication, see the JP1/Base User's Guide.

(2) Restrictions when JP1/AJS3 - Agent is installed in containers

The following shows the restrictions that apply when JP1/AJS3 - Agent is installed in containers:

Logical hosts cannot be created in the container.

JP1/AJS3 can be installed in containers and on the container host machine.

Note, however, that in this case, the version of JP1/AJS3 installed on the container host machine must be 12-60 or later.

In containers, only the following jobs can be used:

Unix job#

QUEUE job

Flexible job

HTTP connection job

Receive JP1 Event job

Monitoring Files job

Receive Mail job

Monitoring Log Files job

Interval Control job

Send JP1 Event job#

Send Mail job#

#

Queueless Agent can also be specified for Exec. Service.

(3) Estimating the system resources required to install JP1/AJS3 - Agent in containers

Before you install JP1/AJS3 - Agent in a container, estimate the system resources that will be used on the agent host that will operate inside the container. Then, add the estimated system resources to the system resources that are used on the container host machine. The values to be added are the same as the values of the system resources on the physical host. If you create multiple containers on one host machine, you must add the estimated system resources for each container. For details about the system resources used by JP1/AJS3 - Agent, see the Release Notes.

3 Estimates

This chapter explains how to make estimates for JP1/AJS3.

Before actually building a system using JP1/AJS3, you must estimate approximate values for the system resources and the kernel parameters.

You might have to consult this chapter again once the system is in operation to revise the estimates and change the values you originally calculated.

3.1 Estimating the processing performance of JP1/AJS3

This section explains how to estimate the processing performance of JP1/AJS3. Follow the explanations given here to achieve the most efficient operation of the work tasks to be automated in a system that uses JP1/AJS3.

3.1.1 Job throughput

When calculating the throughput of a JP1/AJS3 system, you need to consider job execution time as distinct from the JP1/AJS3 processing performance. The execution time of a job runs from the time JP1/AJS3 starts a job execution process until the job has actually ended. Thus, when estimating how many jobs can be executed per unit time, bear in mind both the JP1/AJS3 processing performance and job execution times. You will also need to consider transfer times if large quantities of data are output to the standard error output, or if a large number of files are transferred.

(1) Job processing performance

JP1/AJS3 processing capacity is estimated as the number of job executions per unit of time. You can consider light load conditions, where many "jobs that do nothing" are executed, as giving the peak performance for JP1/AJS3. Check that the number of jobs to be executed is comfortably below this peak performance.

Most jobs tend to be concentrated in particular time periods, so for a balanced performance estimate you have to ensure that the system remains within its peak performance during the period when the concentration of jobs is highest.

When estimating throughput, allow some latitude for the possibility of execution errors and recovery processing.

We recommend, for the sake of simplicity, that you base your estimates on the assumption that 10 times the average number of jobs will be executed during the most concentrated period, and that the daily volume of jobs will use about one tenth of the peak system performance. The following table describes performance estimates for a system that runs jobs 12 hours per day.

Note that the peak performance will vary depending on the hardware you use and other factors.

Table 3‒1: Example estimate for JP1/AJS3 job throughput

Peak performance

(number of jobs executed per second)

Peak performance

(number of jobs executed per hour)

Recommended number of jobs executed per day with 12 hours' operation

0.5

1,800

2,160

1.0

3,600

4,320

2.0

7,200#

8,640

3.0

10,800#

12,960

4.0

14,400#

17,280

5.0

18,000#

21,600

#

In practice, we recommend that you keep the number of jobs started to no more than 5,000.

For example, suppose that 0.5 jobs are executed per second at peak times.

The number of jobs executed per hour in this case will be:

(0.5 jobs) x (3,600 seconds) = 1,800 jobs

Operating 12 hours per day, and at peak performance throughout the day, the number of jobs executed per day would be:

(1,800 jobs) x (12 hours) = 21,600 jobs

Consequently, the recommended number of job executions would be:

(21,600 jobs) / 10 = 2,160 jobs

(2) Event job processing performance

The discussion in (1) Job processing performance above does not apply to event jobs (including those within a start condition) because they have a different execution process from standard jobs.

Certain restrictions apply to event jobs, such as the maximum number of event jobs that can be registered for execution at the same time. Use event jobs judiciously, referring to B.8 Limits for the event/action control.

First estimate the number of events likely to be generated, and keep them to within the system's processing capacity. See 3.1.5 Event monitoring performance.

(3) Activating multiple scheduler services concurrently

When a manager host has two or more CPUs, there are limits to fully utilizing those resources if just one scheduler service is used. We recommend running multiple scheduler services in this situation. For details about using multiple scheduler services, see 4.3.2 Activating multiple scheduler services concurrently.

On a host with only one CPU, running multiple scheduler services within the limits of the CPU's processing capacity might still be an efficient use of resources. We recommend that you consider this option.

(4) Distributing job execution among multiple agent hosts

To utilize the manager host's processing capacity to its fullest extent, we recommend a system configuration in which jobs are executed on multiple agent hosts, thereby helping to reduce the load at the manager host.

For details about configurations that distribute the processing load among multiple agent hosts, see 2.5.2 Load distribution.

(5) OS tuning

(a) TCP/IP parameters

When a JP1/AJS3 system has a large number of jobs to execute, the number of socket ports used for communication between internal processes and between the manager and agent hosts might exceed the OS limit. This can result in job execution delays and abnormal termination of jobs, scheduler services, and commands.

For this reason, you must adjust the OS's TCP/IP parameters to avoid insufficient socket ports at peak loads. Adjust the following parameters:

Number of socket ports

Socket port TIME_WAIT interval

The following table lists the defaults for these parameters in each OS.

Table 3‒2: OS defaults for TCP/IP parameters

OS

Number of socket ports that can be used

TIME_WAIT interval

(seconds)

Windows

16,383

120

HP-UX (IPF)

16,383

60

Solaris

32,768

60

AIX

32,768

15

Linux

28,233

60

The number of socket ports and the value of the TIME_WAIT interval might vary according to the OS version and service pack. See the latest documentation for your OS.

In Windows, you can change the TCP/IP parameters by changing the following registry setting, and then restarting Windows. For the setting procedure, or if using an OS other than Windows, see your OS documentation.

Registry key

\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Parameters

MaxUserPort

TcpTimedWaitDelay

Estimate the maximum number of jobs that can be executed per TIME_WAIT interval as described below, and adjust the TCP/IP parameters as needed.

Note that these adjustments might increase usage of OS resources. For details, see the documentation for your OS.

Estimation

Use the following formula:

Maximum number of jobs that can be executed per TIME_WAIT interval#1

= number-of-available-socket-ports#1, #2, #3 / number-of-ports-used-by-JP1/AJS3#4

#1

Check the actual value set in the OS's TCP/IP parameter.

#2

The value of the OS's TCP/IP parameter is the total number of socket ports available to the system. Therefore, subtract the number used by OS services and by software products other than JP1/AJS3.

#3

If a failed agent is detected when job distribution delay reduction function is enabled, JP1/AJS3 uses a maximum of 1,024 socket ports while conducting a communication status check or communication recovery check.

#4

This is the number of ports that are placed in the TIME_WAIT status when one job is executed by JP1/AJS3.

The number of ports that are placed in the TIME_WAIT status when one job is executed by JP1/AJS3 varies depending on the settings of the reduction of the ports to be used and the communication encryption function.

You can set the reduction of the ports to be used by using the REDUCEUSEPORT environment setting parameter. For details about the REDUCEUSEPORT environment setting parameter, see 20.8.2(5) REDUCEUSEPORT in the JP1/Automatic Job Management System 3 Configuration Guide.

The following table lists the numbers of ports that are placed in the TIME_WAIT status when one job is executed by JP1/AJS3.

Table 3‒3: Number of ports that are placed in the TIME_WAIT status when one job is executed by JP1/AJS3

Setting of the reduction of ports to be used#1

Communication encryption function

Disabled

Enabled

Enabled

Maximum of 4#2

Maximum of 1#2

Disabled

Maximum of 11#2

Maximum of 5#2

#1

If any of the following types of job is used, estimate the maximum number of jobs on the assumption that the reduction of the ports to be used is disabled.

Queue Job

Submit Job

Flexible Job

Event Job

#2

If the agent-monitoring interval (5 minutes by default) is less than the TIME_WAIT interval, estimate the maximum number of jobs while adding 1 to the number-of-ports-used-by-JP1/AJS3.

When estimating the maximum number of jobs, you need to take into consideration the number of ports that are placed in the TIME_WAIT status by an operation on the execution agent. For details about the number of ports that are used by an operation on the execution agent, see 3.2.6 Estimating the number of ports to be used.

Estimation example

This example is for Windows Server 2019, using the OS defaults.

Number of socket ports available to the OS

16,383#

TIME_WAIT interval

120 seconds

If the reduction of the ports to be used is enabled and the communication encryption function is disabled, the number of ports that are placed in the TIME_WAIT status is as follows:

Maximum of 4

Maximum number of jobs that can be executed per TIME_WAIT interval

16,383 / 4 = approx. 4,095

#

This assumes that other software products are not using socket ports. In practice, the number used by OS services and by software products other than JP1/AJS3 needs to be subtracted from this figure.

In this example, if more than 4,095 jobs are executed within 120 seconds, the socket ports will run out, causing delays and other potential problems. If this could occur in your system, you will need to change the TCP/IP parameter settings to adjust the maximum number of jobs that can be executed.

3.1.2 Response of JP1/AJS3 - View

When using JP1/AJS3 - View, you can calculate an approximate value for the response time from JP1/AJS3 - Manager with the following formula.

Response time =

Processing-time-at-JP1/AJS3 - Manager

+ data-transfer-time

+ drawing-time

(1) JP1/AJS3 - Manager processing time

If the processing performance of the computer in which JP1/AJS3 - Manager is installed is low, the processing time will be long. The processing at JP1/AJS3 - Manager is shown below:

Connection (user authentication)

Updating user definition information and acquiring actual schedule and actual result data

Operations on units

(a) Connection (user authentication)

When you connect from JP1/AJS3 - View to JP1/AJS3 - Manager, the authentication server is accessed to authenticate the user. If the computer running the authentication server has not been started, or multiple authentication servers are used, there will be a corresponding increase in processing time.

(b) Updating unit definition data and acquiring actual schedule and actual result data

The processing at JP1/AJS3 - Manager differs according to the type of request from JP1/AJS3, but since in the main it will be searching for, referencing, and updating definitions and statuses stored in the disk, it tends to be affected by disk performance.

Processing will take time particularly if there are many component elements in the Monthly Schedule window, the Daily Schedule window, or the JP1/AJS3 - View window (Summary Monitor window), and jobnets with many execution generations are displayed, or when job group statuses are displayed in the JP1/AJS3 - View window (Main window). The performance of the CPU also affects calculation of execution schedules.

To increase stability of performance, you must estimate the entire load on the server, taking into account the frequency of disk access by other applications, the circumstances of CPU use, and so on.

(c) Operations on units

When a lengthy fixed-execution registration is done for a jobnet with many component elements, or the registration of a jobnet with a very large number of logs to keep setting is canceled, the processing time at JP1/AJS3 - Manager will be long. Under conditions such as these, communications processing might time out at JP1/AJS3 - View, and the message KAVV402-E (A timeout occurred while waiting for the response from the connection-destination) might be displayed. Consider reviewing operations to avoid long processing times in JP1/AJS3 by shortening the fixed registration period, setting a smaller number of logs to keep, and so on. If you cannot review operations, change the timeout value by following the corrective action advised for the error message KAVV402-E. The default for this timeout value is 30 minutes. The appropriate timeout value will differ depending on the nature of the processing at JP1/AJS3 - Manager, the condition of the network, and the performance of the computer. Measure the response time in the environment you are using and estimate an appropriate value. After measuring a sufficiently large response time, set a value larger than the measured value as the timeout value (there should be some leeway).

(2) Data transfer time

The data transfer time is affected by the network performance between JP1/AJS3 - View and JP1/AJS3 - Manager.

The data transfer time also lengthens as the number of units displayed and number of executed generations increase. If the network you are using is a slow one, consider the following measures.

Do not automatically refresh screens, or lengthen the update interval.

Reduce the number of elements (jobs, jobnets, etc.) displayed on one screen.

(3) Drawing time

The main influence on the display performance of JP1/AJS3 - View is the performance of the JP1/AJS3 - View host. If the processing speed of the JP1/AJS3 - View host is slow, drawing takes time. If the number of displayed units and relation lines and the number of logs to keep increase and you feel that the drawing speed is slower than before, consider upgrading the computer on which JP1/AJS3 - View is installed.

Display will take time and the memory area used will increase particularly if the schedule settings in the Monthly Schedule window and the Daily Schedule window call for the display of tens of thousands of execution generations or job groups consisting of hundreds of jobnets. Accordingly, when performing operations using the Monthly Schedule window or Daily Schedule window, consider upgrading the computer on which JP1/AJS3 - View is installed.

3.1.3 Response of Web GUI

When using Web GUI, you can calculate an approximate value for the response time from JP1/AJS3 - Manager with the following formula.

Response time =

Processing-time-at-JP1/AJS3 - Manager

+ data-transfer-time

+ Processing-time-at-Web-Console-server

+ drawing-time

(1) JP1/AJS3 - Manager processing time

If the processing performance of the computer in which JP1/AJS3 - Manager is installed is low, the processing time will be long. The processing at JP1/AJS3 - Manager is shown below:

Connection (user authentication)

Acquiring execution schedule and execution result data of the unit

Operations on units

Operations on execution agents

(a) Connection (user authentication)

When you connect from Web GUI to JP1/AJS3 - Manager, the authentication server is accessed to authenticate the user. If the computer running the authentication server has not been started, or multiple authentication servers are used, there will be a corresponding increase in processing time.

(b) Acquiring execution schedule and execution result data of the unit

The processing at JP1/AJS3 - Manager differs according to the type of request from the Web GUI but it mainly searches for or references the statuses stored on a disk. Therefore, the processing tends to be influenced by the disk performance.

Processing takes more time when it displays a jobnet with many components and many execution generations. The calculation of the execution schedule is also influenced by the CPU performance.

To increase stability of performance, you must estimate the entire load on the server, taking into account the frequency of disk access by other applications, the circumstances of CPU use, and so on.

(c) Operations on units

When a lengthy fixed-execution registration is done for a jobnet with many component elements, or the registration of a jobnet with a very large number of logs to keep setting is canceled, the processing time at JP1/AJS3 - Manager will be long. Under such conditions, the communication processing might time out at JP1/AJS3 - Manager. Consider reviewing operations to speed up the processing time in JP1/AJS3 - Manager by, for example, reducing the fixed registration period or setting a smaller number of logs to keep.

If you are not able to review operations, change the timeout value. The default for this timeout value is 3 minutes. The appropriate timeout value will differ depending on the nature of the processing at JP1/AJS3 - Manager, the condition of the network, and the performance of the computer. Measure the response time in the environment you are using and estimate an appropriate value. After measuring a sufficiently large response time, set a value larger than the measured value as the timeout value (there should be some leeway).

(d) Operations on execution agents

If operations are performed simultaneously on multiple execution agents, the processing time increases in proportion to the number of target execution agents. In this situation, communication processing might time out. If a timeout occurs, reduce the number of target execution agents, and then try again.

(2) Data transfer time

The data transfer time is influenced by the network performance between the Web GUI, Web Console server, and JP1/AJS3 - Manager.

(3) Processing time in the Web Console server

If the processing performance of the computer in which JP1/AJS3 - Web Console is installed is low, the processing time will be long. The processing at JP1/AJS3 - Web Console is shown below:

Processing a request from the Web GUI

(a) Processing a request from the Web GUI

The Web Console server processes requests for authentication, unit manipulation, information acquisition and the like from the Web GUI, and sends the request to JP1/AJS3 - Manager. The processing takes time if there are frequent processing requests from the Web GUI, or if many Web GUIs are connected. To increase performance stability, you need to estimate loads on overall server machines considering the number of Web GUIs that can be concurrently connected and CPU usage.

(4) Drawing time

The display performance of the Web GUI basically depends on the machine performance of the Web GUI. Consider upgrading the machine if you find that the processing speed of the host is low and drawing takes time.

3.1.4 Response of user applications that use API functions

If you create an original user application that uses API functions, the response time from JP1/AJS3 - Manager can be estimated using the following equation:

Response time =

Processing-time-at-JP1/AJS3 - Manager

+ data-transfer-time

+ Processing-time-at-Web-Console-server

+ Processing-time-at-user-application

(1) JP1/AJS3 - Manager processing time

If the processing performance of the computer in which JP1/AJS3 - Manager is installed is low, the processing time will be long. The processing at JP1/AJS3 - Manager is shown below:

Connection (user authentication)

Acquiring execution schedule and execution result data of the unit

Operations on units

Operations on execution agents

(a) Connection (user authentication)

When a user application connects to JP1/AJS3 - Manager, the application accesses the authentication server for user authentication processing. If the computer running the authentication server has not been started, or multiple authentication servers are used, there will be a corresponding increase in processing time.

In user applications, a user must be authenticated every time the application issues an API request. Therefore, the processing time becomes longer if the application issues a lot of requests.

(b) Acquiring execution schedule and execution result data of the unit

The processing at JP1/AJS3 - Manager differs according to the type of request from the user application but it mainly searches or references the statuses stored on a disk. Therefore, the processing tends to be influenced by the disk performance.

Processing takes more time when it displays a jobnet with many components and many execution generations. The calculation of execution schedule is also influenced by the CPU performance.

To increase stability of performance, you must estimate the entire load on the server, taking into account the frequency of disk access by other applications, the circumstances of CPU use, and so on.

(c) Operations on units

When a lengthy fixed-execution registration is done for a jobnet with many component elements, or the registration of a jobnet with a very large number of logs to keep setting is canceled, the processing time at JP1/AJS3 - Manager will be long. Under such conditions, the communication processing might time out at JP1/AJS3 - Manager. Consider reviewing the user application design to speed up the processing time in JP1/AJS3 - Manager by, for example, reducing the fixed registration period or setting a smaller number of logs to keep.

(d) Operations on execution agents

If operations are performed simultaneously on multiple execution agents, the processing time increases in proportion to the number of target execution agents.

(2) Data transfer time

The data transfer time is influenced by the network performance between the user application, Web Console server, and JP1/AJS3 - Manager.

(3) Processing time in the Web Console server

If the processing performance of the computer in which JP1/AJS3 - Web Console is installed is low, the processing time will be long. The processing at JP1/AJS3 - Web Console is shown below:

Processing a request from a user application

(a) Processing a request from a user application

The Web Console server processes requests for authentication, unit manipulation, information acquisition, or other requests from the user application, and sends the requests to JP1/AJS3 - Manager. The processing takes time if there are frequent processing requests from the user application, or if many user applications are connected. To increase performance stability, you need to estimate the loads on the entire server machines considering the number of user applications that can be concurrently connected and CPU usage.

(4) Processing time in a user application

The processing time in a user application is influenced by the machine processing performance or the method used for deploying the user application. If the processing speed of a user application is low, consider the following:

Increasing the processing performance by machine upgrades, etc.

Reviewing the design and deployment method for the user application

Reviewing the target unit, for example by limiting the units to be processed

3.1.5 Event monitoring performance

If you intend to monitor events using JP1/AJS3 event jobs and jobnets with start conditions, you must first estimate the number of event jobs that will be executed and the number of generated events, and keep monitoring to within the JP1/AJS3 processing performance.

This subsection describes how to estimate and set the processing performance of JP1/AJS3 in regard to monitoring events.

Processing performance estimates for event monitoring are based on how long it takes an event job or a jobnet with a start condition to be ready to process the next event after a preceding event occurs. If events occur at shorter intervals than the estimated length of time, a bottleneck of event jobs and jobnets with start conditions might occur, potentially delaying the processing of other jobnets. In cases where you can predict how frequently events will be generated, we recommend setting monitoring conditions that will not result in events occurring at shorter intervals than predicted.

Bottlenecks might also occur when a number of events are being monitored and two or more occur at roughly the same time. Avoid monitoring types of events that are likely to occur at the same time.

The processing time for monitoring one event is approximately 0.6 seconds, depending on the hardware and other factors.

You can also estimate the processing capacity for monitoring events by a scheduler service, based on how many events are generated at the scheduler service per unit time. We recommend a system design that will keep the number of events reported to the scheduler service at a level well below the value calculated using the following formula:

At jobnet registration

Length of time until the jobnet can be executed (seconds) = number of event jobs# x 0.8

#

Total number of event jobs (including jobnets with start conditions) registered for execution at the same time

At event occurrence

Number of events that can be processed = unit of time (seconds) / 0.6

Example: Calculate the number of events that can be processed in 60 seconds.

Number of events that can be processed = 60 / 0.6 = 100

Thus, 100 jobs can be processed in 60 seconds.

This formula gives the peak processing performance (that is, the processing capacity when only event jobs and jobnets with start conditions are processed).

Keep the number of events to no more than 1,000 per hour per scheduler service, even at peak times.

Performance when the event order option is used

When the event order option is used, an agent that has sent an event to the manager does not send the next event until it receives a reply from the manager. Processing that checks for a reply from the manager is performed at regular intervals (every ten seconds), and the agent sends the next event only after a reply is received from the manager. Accordingly, the maximum number of events that can be processed per hour is 360. We recommend that you estimate 180 events being processed per hour when the event order option is specified, although the actual value will depend on how often events occur in the particular system.

3.1.6 Monitoring interval set when using the Monitoring Files job

This subsection explains how to estimate the monitoring interval time to be set when using Monitoring Files jobs. If you execute many Monitoring Files jobs at the same time and with the same monitoring interval in JP1/AJS3, the processing for all the jobs might not finish within the set monitoring interval. If you continue operation under these circumstances, file updating will not be monitored correctly at the set interval time, so that a longer time than the monitoring interval might elapse between the updating of a monitored file and the generation of an event. You must therefore calculate the monitoring interval time to be set when multiple Monitoring Files jobs are executed by using the following estimation formula.

(1) Monitoring interval time estimation formula

Select the larger of the values obtained with the following estimation formulae as the monitoring interval time:

- Estimation formula 1 = (A x number-of-executed-jobs) + (sum-of-B)

- Estimation formula 2 = (C x number-of-executed-jobs) + (sum-of-D) + (E x peak-number-of-event-occurrences#) + (sum-of-F-when-number-of-event-occurrences-is-at-peak)

#

The peak number of event occurrences is the maximum number of events occurring per minute.

Table 3‒4: Processing time per Monitoring Files job

When the full name of the monitored file is specified

When a wildcard (*) is used in the specification of the monitored file

(at registration)

A Approx. 0.1 seconds

B 0.1 seconds + 0.2 seconds added for each multiple of 10 monitored files

(during monitoring)

C Approx. 0.02 seconds

D 0.02 seconds + 0.2 seconds added for each multiple of 10 files matching the wildcard#

(when events occur)

E Approx. 0.9 seconds

F 0.9 seconds + 0.2 seconds added for each monitored file matching the condition within the monitoring interval

#

Estimate the number of files matching the wildcard as the maximum number of files being monitored.

Note

Values vary depending on the hardware you use.

(2) Example estimation of monitoring interval time set for Monitoring Files jobs

This example is based on the following prerequisites.

There are 97 Monitoring Files jobs in which the target files are specified by full name.

There are three Monitoring Files jobs (X, Y, and Z) in which the target file names are specified by wildcard (*).

The peak number of events is 50 for the Monitoring Files jobs with target files specified by full name.

A maximum of 35 files exist in the directory being monitored by job X, and 20 events occur within the monitoring interval.

A maximum of five files exist in the directory being monitored by job Y, and two events occur within the monitoring interval.

A maximum of nine files exist in the directory being monitored by job Z, and nine events occur within the monitoring interval.

When estimation formula 1 is applied:

(0.1 x 97) +

(0.1 + 0.2 x (35 / 10)) + (0.1 + 0.2 x (5 / 10)) + (0.1 + 0.2 x (9 / 10)) = 9.7 + 0.8 + 0.2 + 0.28 = 10.98 (seconds)

Round up to 11 seconds.

When estimation formula 2 is applied:

(0.02 x 97) + (0.02 + 0.2 x (35 / 10)) + (0.02 + 0.2 x (5 / 10)) + (0.02 + 0.2 x (9 / 10)) + (0.9 x 50) + (0.9 + (0.2 x 20)) + (0.9 + (0.2 x 2)) + (0.9 + (0.2 x 9)) = 1.94 + 0.72 + 0.12 + 0.2 + 45 + 4.9 + 1.3 + 2.7 = 56.88 (seconds)

Round up to 57 seconds.

In this example, estimation formula 2 gives the larger value, so you should set a value of 57 or higher for the monitoring interval time.

3.2 Estimating system performance

To ensure optimal performance of a system that uses JP1/AJS3, it is important to estimate the optimum values for the networks that make up the system, and the system resources, such as memory and the kernel parameters. This section explains how to estimate the system performance required to use JP1/AJS3.

3.2.1 Estimating the data flow on the network

We will explain how to estimate the following data volumes:

Between JP1/AJS3 - Manager and JP1/AJS3 - Agent

Between JP1/AJS3 - View and JP1/AJS3 - Manager

Between Web Console server and JP1/AJS3 - Manager

Between Web GUI and Web Console server

Between a user application and the Web Console server

(1) Estimating the data volume between JP1/AJS3 - Manager and JP1/AJS3 - Agent

You need to estimate the data involved in job executions and the transferring of execution results.

The following table shows an estimate for the volume of data between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

Estimate the same data volume when using queueless jobs too.

Table 3‒5: Estimate of data volume between JP1/AJS3 - Manager and JP1/AJS3 - Agent

Type of information

Estimated volume of transferred data per job (units: bytes)

Job execution request transfers

When a job is executed from a jobnet:

2,300

+ contents-defined-in-the-definition-information-for-a-Unix job,-PC-job,-flexible-job,-and-HTTP-connection-job#1

+ (8 x number-of-specified-environment-variables)

+ unit-full-name-length x 2

+ agent-host-name-size x 2

+ manager-host-name-size x 3

+ transfer-file-size#2

When a job is executed by using the jpqjobsub command:

2,300

+ total-size-of-the-options-in-the-jpqjobsub-command-and-the-values-specified-for-the-options

+ (8 x number-of-specified-environment-variables)

+ agent-host-name-size x 2

+ manager-host-name-size x 3

+ transfer-file-size#2

Job result transfers

600

+ manager-host-name-size

+ agent-host-name-size

+ result-file-size (standard output, standard error output)#3

Event job execution request transfers

Minimum: 256

Maximum: 25,600

Event job result transfers

Minimum: 512

Maximum: 7,168

#1

For details on what is defined in each piece of job definition information, see the following manuals:

ajsprint in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference

5.2.6 UNIX/PC job definition in the manual JP1/Automatic Job Management System 3 Command Reference

5.2.26 Flexible job definition in the manual JP1/Automatic Job Management System 3 Command Reference

5.2.27 HTTP Connection job definition in the manual JP1/Automatic Job Management System 3 Command Reference

To pass the information sent from an event job to the target job, add the size of the macro variables in the above estimate. For details about the size of the information to be passed to each type of event job, see B. Information Passed by Event Jobs in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

#2

The formula for estimating the size of the transfer file is as follows:

file-count

(file-name-length + file-size + (12 x number-of-lines-in-file) + 100)

#3

The formula for estimating the size of the result file is as follows:

file-count

(result-file-size + (12 x number-of-lines-in-file) + 116)

In cases where the system monitors an agent host where a problem not in the above table occurred, or where jobs registered for execution are monitored by polling, data is exchanged between JP1/AJS3 - Manager and JP1/AJS3 - Agent. The volume of data per polling in such cases is shown below. Note that polling cannot monitor queueless jobs.

Table 3‒6: Estimated data volume between JP1/AJS3 - Manager and JP1/AJS3 - Agent when monitoring by polling

Type of data

Estimated volume of transferred data per polling (units: bytes)

Agent host status confirmation request transfers during trouble

300

Status confirmation request transfers for jobs being executed

350 + size-of-agent-host-name

(2) Estimating the data volume between JP1/AJS3 - View and JP1/AJS3 - Manager

You need to estimate the volume of data relating to such items as the definition of jobnets. Since the data size for communications for operation and so on is relatively small, we will not estimate it here.

The estimated volume of data between JP1/AJS3 - View and JP1/AJS3 - Manager is shown in the table below.

Table 3‒7: Estimated volume of data between JP1/AJS3 - View and JP1/AJS3 - Manager

Window displayed

Estimated volume of transferred data (units: bytes)

JP1/AJS3 - View (Main window)

number-of-units x 500

JP1/AJS3 - View (Summary Monitor window)

total-number-of-schedules#1 x 400

Jobnet Editor

number-of-units x 250 + number-of-relation-lines x 50

Jobnet Monitor

number-of-units x 300 + number-of-relation-lines x 50

Daily Schedule or Monthly Schedule

total-number-of-schedules#1, #2 x 150

Search

number-of-search-results x 450

#1

This is the number of execution schedules and execution results for all of the units under the root jobnet.

If a job group is specified for operation, this number is the number of execution schedules and execution results for all of the units under the root jobnet directly under the job group.

#2

This item also includes the number of schedules for unregistered units when the Monthly Schedule window displays execution schedules for unregistered units.

The following are some example estimates of data volumes:

When a jobnet defined with 300 units and 100 relation lines is checked in the Jobnet Monitor window:

300 x 300 + 100 x 50 = 95,000 (units: bytes)

When the execution schedule and execution results for an operation in which the daily execution of 100 jobnets with 100 jobs defined for them is planned is checked in the Daily Schedule window:

100 x 100 x 150 = 1,500,000 (units: bytes)

JP1/AJS3 - View acquires information from JP1/AJS3 - Manager automatically at regular intervals. The defaults are 30 seconds for the Jobnet Monitor window, and 300 seconds for other windows. Settings can be made from 30 seconds upward. When you have to estimate the volume of data flowing in the network, make the calculation based on the update interval of JP1/AJS3 - View and the data size required for each window.

(3) Estimating the data volume between Web Console server and JP1/AJS3 - Manager

You need to estimate the data volume related to such items as acquiring jobnet statuses. Since the data size for communications for operation and so on is relatively small, we will not estimate it here.

The estimated volume of data between Web Console server and JP1/AJS3 - Manager is shown in the table below.

Table 3‒8: Estimated volume of data between Web Console server and JP1/AJS3 - Manager

Type of data

Estimated volume of transferred data (units: bytes)

Information required to display the Dashboard screen

sum-of-the-volume-of-data-used-by-each-monitored-unit#1 + 10,900

Information required to display the List screen

number-of-units x 370 + 2,100

Information required to display the Monthly Schedule screen

18,300 + number-of-units x (total-number-of-schedules#2 + number-of-schedules-for-a-single-day#3) x 440

Information required to display the Monitor dialog box#4

number-of-units x 820 + number-of-relation-lines x 50 + 22,430

Information acquired by a unit summary acquisition API function

number-of-units x 4,400 + 3,025

Information required to display the Execution Agent Management screen

number-of-execution-agents x 800 + 5,300

Information required to display the Execution Agent Group Management screen

number-of-execution-agent-groups x (500 + (number-of-associated-execution-agents x 300)) + 5,300

#1

The following formula is used to estimate the volume of data used for each monitored target.

number-of-units x the-number-of-generations-on-the-monitoring-target-date x 1,600 + 2,740

#2

This number indicates the total number of execution schedules and execution results for the month displayed in the Schedule area. This number also includes the number of schedules for unregistered units.

#3

This number indicates the total number of execution schedules and execution results for a single day displayed in the List area. This number also includes the number of schedules for unregistered units.

#4

The estimated volume of data transmitted for the Monitor screen is the same as that transmitted for the Monitor dialog box.

The following shows an example estimate when 20 units match the condition of the unit summary acquisition API function:

20 x 4,400 + 3,025 = 91,025 (unit: bytes)

(4) Estimating the data volume between Web GUI and Web Console server

You need to estimate the data volume related to such items as acquiring jobnet statuses. Since the data size for communications for operation and so on is relatively small, we will not estimate it here.

The estimated volume of data between Web GUI server and Web Console server is shown in the table below.

Table 3‒9: Estimated volume of data between Web GUI and Web Console server

Window displayed

Estimated volume of transferred data (units: bytes)

Dashboard screen

sum-of-the-volume-of-data-used-by-each-monitored-unit#1 + 20,200

List screen

number-of-units x 4,700 + 3,700

Monthly Schedule screen

4,000 + (number-of-units x number-of-days-for-which-schedules-exist#2 x 1,400) + (number-of-schedules-for-a-single-day#3 x 1,200)

Monitor dialog box#4

number-of-units x 4,100 + number-of-relation-lines x 70 + 13,200

Apply Operating Permission Settings dialog box#5

file-size-of-the-Operating-Permission-Configuration-File-specified-in-the-Apply-Operating-Permission-Settings -dialog-box + 1,700

Message dialog (Confirmation of the acquisition of the Operating Permission Configuration File)#6

file-size-of-the-Operating-Permission-Configuration-File-applied-to-the-host-to-which-a-connection-is-to-be-established + 1,100

Information required to display the Execution Agent Management screen

number-of-execution-agents x 800 + 1,200

Information required to display the Execution Agent Group Management screen

number-of-execution-agent-groups x (500 + (number-of-associated-execution-agents x 300)) + 1,000

#1

The following formula is used to estimate the volume of data used for each monitored target.

number-of-units x the-number-of-generations-on-the-monitoring-target-date x 3,900 + 1,590

#2

This number indicates the number of days for which execution schedules and execution results, which are displayed in the Schedule area, exist. This number also includes the number of schedules for unregistered units.

#3

This number indicates the total number of execution schedules and execution results for a single day for the unit displayed in the List area. This number also includes the number of schedules for unregistered units.

#4

The estimated volume of data transmitted for the Monitor screen is the same as that transmitted for the Monitor dialog box.

#5

Data to be used if the operation restriction function is enabled.

This dialog box is for specifying the Operating Permission Configuration File to be applied. This dialog box is displayed when Management - Operating Permission Settings - Apply is selected in the menu. The maximum size of the Operating Permission Configuration File is 3 megabytes.

#6

Data to be used if the operation restriction function is enabled. This dialog box is for confirming whether to acquire the Operating Permission Configuration File. This dialog box is displayed when Management - Operating Permission Settings - Acquire is selected in the menu. The maximum size of the Operating Permission Configuration File is 3 megabytes.

The following are some example estimates of data volumes:

If there are 10 units to be monitored, 99 units are defined under the each monitored target, each unit is scheduled to be performed once on the monitoring-target date, and the window to be displayed is the Dashboard screen:

10 x (100 x 1 x 3,900 + 1,590) + 20,200 = 3,936,100 (unit: bytes)

If a jobnet under which 300 units and 100 relation lines are directly defined is to be displayed in the Monitor dialog box:

300 x 4,100 + 100 x 70 + 13,200 = 1,250,200 (unit: bytes)

To display 1 root jobnet with 500 subordinate units, 10 execution schedules per day, repeating daily (including holidays), in the Monthly Schedule screen:

4,000 + 501 x 43,600 + 300 x 1,200 = 22,207,600 (units: bytes)

Note that if automatic update is set to ON in the Web GUI, the Web Console server communicates with the Web Console server and with JP1/AJS3 - Manager at regular intervals.

(5) Estimating the data volume between a user application and the Web Console server

You need to estimate the data volume related to such items as acquiring jobnet statuses. Since the data size for communications for operation and so on is relatively small, we will not estimate it here.

The following table shows the estimated volume of data transferred between a user application and the Web Console server.

Table 3‒10: Estimated volume of data transferred between a user application and the Web Console server

Type of data

Estimated volume of transferred data (units: bytes)

Unit summary acquisition API function

number-of-units x 7,040 + 2,600

The following shows an example of estimating the transfer data volume when 20 units match the condition of the unit summary acquisition API function:

20 x 7,040 + 2,600 = 143,400 (units: bytes)

3.2.2 Estimating the amount of communications in line connections

For the amount of traffic in a WAN environment, see 2.3.7 Communications used in a WAN.

3.2.3 Estimating the size of memory used

For the JP1/AJS3 memory requirements, see the Release Notes.

3.2.4 Estimating disk capacity

For details about JP1/AJS3 disk capacity, see the Release Notes. However, to estimate the size of user-defined data that is not included in the embedded database in the estimation methods described in the Release Notes, use the procedure below.

There are two cases when estimating user-defined data. In one, the unit for estimation is logical hosts. In the other, the unit is scheduler services.

See the following for details.

(1) Estimation on a logical host basis

When you add logical hosts, you need to estimate the size of user data for each logical host. Use the following formulas for estimating user data by logical host.

Table 3‒11: Estimation of user data by logical host

User-defined data

Value or formula (units: megabytes)

Data for the execution environment for QUEUE jobs and submit jobs (such as queues)#1

4

Execution logs for QUEUE jobs and submit jobs (such as job information, the standard error output file, and the standard output file)#1, #2

a x (0.0095 + b + c)

Files such as the standard output file or the standard error output file #3

0.5 x d

Legend:

a:

Number of job information items for QUEUE jobs and submit jobs

Use the following formula:

number-of-QUEUE-jobs-and-submit-jobs-that-are-executed-per-day x (number-of-days-job-information-retained + 1)

b:

Environment variable size specified in the job execution definition for QUEUE jobs and submit jobs (the maximum is 20 KB; 0 is set when no environment variables are used)

c:

Size of the data output to the standard error output file and the standard output file by submit jobs

d:

Maximum number of concurrently executable jobs for an agent (standard: 5)

#1

Estimation is required only when QUEUE jobs and submit jobs are used in the standard configuration. Estimation is not required for a standard configuration without ISAM.

For the execution environment and execution logs for QUEUE jobs and submit jobs, estimate the disk space requirements for the database directory in the execution environment for QUEUE jobs and submit jobs. If the directory has been changed, estimate the disk space requirements for the directory after the change.

#2

For a standard configuration, a, b, and c must be estimated for the number of QUEUE jobs and submit jobs. Each time a QUEUE job or submit job is executed, an execution log for that job is saved. Execution logs are deleted when their retention period (number of days) expires. Note, however, that the size of the database used for the execution environment for QUEUE jobs and submit jobs is not reduced at the moment execution logs are deleted. Accordingly, you need to perform periodic maintenance for the ISAM files used in this execution environment.

For details about how to perform maintenance, see 5.2.2 How to check the unused area of the ISAM files used in the execution environment for QUEUE jobs and submit jobs, and when the database should be reorganized in the JP1/Automatic Job Management System 3 Administration Guide. For details about how to change the number of days for retaining job information, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

#3

This item depends on the parameters used for job execution, such as the standard output file, the standard error output file, environment variables, and transfer files. As a rough estimate, a job requires 0.5 megabytes multiplied by the maximum number of concurrently executable jobs for an agent (standard: 5). However, if you can estimate an average value for the files described above, change the default value for calculation.

(2) Estimation on a scheduler service basis

When you add scheduler services, you need to estimate the size of user data for each scheduler service. Use the following formulas to estimate the size of user data by scheduler service.

Table 3‒12: Estimation of user data by scheduler service

User-defined data

Value or formula (units: megabytes)

Job information per root jobnet#1, #6

number-of-logs-to-keep x total-size-of-standard-output-and-standard-error-output-for-all-jobs-under-root-jobnet

Disk space required for the information for each event job#1, #7, #8

number-of-logs-to-keep x number-of-event-jobs-with- event-job-passing-information-set x 0.004

Event job execution environment data (such as unreported information)#2

100#3

Disk space to be used by the temporary change operation management function#4, #7

0.001 + a

Data size of job execution environment (job information)#5

15.2

Legend:

a: The total size of the temporary change information

Calculate the total of the temporary change information size for each root jobnet. To do so, use the following equation:

0.002 x A + 0.003 x B

A: The number of the operations performed on the root jobnet and its lower units that are to be saved as temporary change information

B: The number of operations in A that are performed to add execution schedules by specifying passing information

Temporary change information increases every time you perform an operation that is saved as temporary change information on the root jobnet and its lower units. Note, that for a root jobnet and its lower units for which the expired temporary change information is stored, the expired temporary change information is automatically deleted when you perform an operation that is saved as temporary change information. For details about the operations that are saved as temporary change information and the expiration date of temporary change information, see 4.5.16(1) Displaying temporary change information in the manual JP1/Automatic Job Management System 3 Overview.

#1

Estimate the total for all the registered root jobnets.

Because the data is stored in the directory for job error information, estimate the disk space for the new directory if the storage destination in the JOBINFDIR environment setting parameter is changed.

#2

When an event job (including one set in a start condition) is executed, the definition data of the executed event job and the information about the event when the monitoring condition is satisfied are exchanged between processes such as the event/action control manager and the event/action control agent. During that time, if communication fails because of a temporary network failure or because the destination process is busy, the information to be sent is temporarily stored in a file as unreported information and then re-sent after a preset interval.

The estimated size for unreported information is the maximum size needed to retain the information.

Note that unreported information is deleted when retransmission is successful.

#3

This value is calculated as follows:

Disk space for unreported information = (0.025 x A) + (0.005 x B) (units: megabytes)

A: Number of events one scheduler service can process per hour

B: Number of retained items of unreported information that is to be sent from event/action control to schedule control

If all the data to be transmitted between the event/action control manager and the event/action control agent becomes unreported information, the maximum for A becomes 1,000. For details about the number of events that one scheduler service can process per hour, see 3.1.5 Event monitoring performance.

If all the data to be sent from event/action control to schedule control becomes unreported information, the maximum for B becomes 15,000.

If all the unreported information is retained, the maximum disk space for unreported information is (0.025 x 1,000) + (0.005 x 15,000) = 100 (units: megabytes).

#4

Estimated only when the temporary change operation management function is used.

Because this data is stored in the directory for job error information, estimate the disk space of the actual directory if you have changed the storage directory.

#5

The size of the data used by the job execution control manager process (jpqman) of each scheduler service to manage job information

#6

If you use an external database, you need to estimate the volume of user data only if you use the -i %so option, the -f %r option, or the -r option of the ajsshow command. In this case, the contents of the standard output and the standard error output of the job specified for the ajsshow command are output to the directory specified for the STDFILEOUTDIR environment setting parameter. For this reason, estimate only the disk capacity required for the number of times the ajsshow command is executed. Note, as well, that the execution results of the ajsshow command are not automatically deleted. Manually delete them as needed.

#7

When an external database is used, the amount of used disk space is 0.

#8

When the backup enhancement function is used, the amount of used disk space is 0.

Supplementary notes

Of the user data used by scheduler services, jobnet definitions and job execution information are included in the embedded database.

For details about how to estimate the disk space used by the embedded database, see 23.2 Estimating the database area in the JP1/Automatic Job Management System 3 Configuration Guide.

For details about how to estimate the disk space requirements after migration from a version 8 embedded database, see 8.5.2(7) Estimating the disk space requirements after migration from a version 8 embedded database.

3.2.5 Estimating the values for kernel parameters

When using JP1/AJS3 in a UNIX environment, adjust the OS's kernel parameters to allocate the resources needed to execute JP1/AJS3. For details about the kernel parameters that you need to adjust, see the Release Notes.

3.2.6 Estimating the number of ports to be used

Estimate the number of ports that will be used by referring to the following description.

(1) Operations on execution agents

When commands or JP1/AJS3 - Web Console is used to operate execution agents, ports on the manager host are used. Use the expression shown in the following table to estimate the number of ports that will be used when execution agents are operated.

Table 3‒13: Estimating the number of ports that will be used when execution agents are operated

Item

Estimation formula

Number of ports to be used

number-of-execution-agents-to-be-operated x 8

3.3 Estimating the database area

The database area is constantly expanded little by little whenever there is insufficient space, limited only by the size of the disk drive that the data area is configured on.

To customize the size of the database area, see 23.2 Estimating the database area in the JP1/Automatic Job Management System 3 Configuration Guide.

3.4 Estimating log sizes

This section describes the formulae used to estimate the size of the log files that JP1/AJS3 outputs. When a problem occurs, log file information is used to identify the operation or processing that caused it. If there is insufficient information in the log file to do this, it takes some time to determine the cause. You should therefore make the best estimate you can for the appropriate log file size, considering the mode of operation used for the processing you are executing.

3.4.1 Estimating the size of scheduler log files

This subsection explains how to estimate the size of scheduler log files. The execution logs and operation logs of jobnets and jobs are output to the scheduler log, and this information is used mainly for monitoring the execution statuses of applications. The required size for scheduler log files differs greatly depending on the following considerations.

The mode of the application's operations (jobnet structure)

The number of JP1/AJS3 - View connections

The nature of the operations

The specifications for the environment setting parameters of the configuration definitions

AJSLOG

NETLOG

JOBLOG

OPELOG

REFLOG

INFOLOG

AJSLOGOUTPUTEXTEND

The output destination of scheduler log file (per host or scheduler service)

You should therefore estimate an appropriate size for the scheduler log files and change the default disk capacity as required. For details about the default disk capacity and the maximum disk area used for the scheduler log, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

The flow for estimating scheduler log file size is shown below.

Figure 3‒1: Flow for estimating scheduler log file size

(1) Formula for estimating scheduler log file size

The number of formulas that are required for estimating the size of the scheduler log file by scheduler service differs depending on the values set for environment setting parameters. Select the required formulae based on the conditions listed in the following table.

Table 3‒14: Formulas for estimating scheduler log file size

Settings for scheduler service configuration definitions

Estimation formula (size: kilobytes)

When all is set for the environment setting parameter AJSLOG

A =

80 x (scheduler-service-start-count + scheduler-service-end-count)

/ 1,024

When a setting other than none is set for the environment setting parameter NETLOG

B =

{ (90 + maximum-length-of-jobnet-name)

x (number-of-jobnets-started-per-day + number-of-jobnets-ended-per-day + number-of-start-condition-monitoring-processes-started + number-of-start-condition-monitoring-processes-ended + number-of-jobnets-with-hold-setting + number-of-jobnets-being-monitored-for-start-and-end-delays) }

/ 1,024

When a setting other than none is set for the environment setting parameter JOBLOG

C =

{ (120 + maximum-job-name-length + maximum-length-of-the-job-execution-agent-name)

x (number-of-jobs-under-the-root-jobnet-started-per-day + number-of-jobs-under-the-root-jobnet-ended-per-day + number-of-jobs-with-hold-setting) }

/ 1,024

When a setting other than none is set for the environment setting parameter OPELOG or REFLOG

D =

{ (100 + maximum-length-of-JP1-user-names-that-execute-commands + maximum-length-of-logical-host-names + maximum-length-of-options-specified-for-commands-that-operate-units-and-are-specified-for-output-to-a-log)

x (total-execution-count-of-commands-that-do-not-operate-units-and-have-been-specified-to-output-a-log + total-number-of-units-subject-to-commands-that-operate-units-and-have-been-specified-to-output-a-log) }

/ 1,024

When a setting other than none is set for the environment setting parameter INFOLOG

E =

{ (100+ maximum-length-of-JP1-user-names-that-execute-commands + maximum-length-of-logical-host-names + maximum-length-of-options-specified-for-commands)

x (total-execution-count-of-commands-that-do-not-operate-units-and-have-been-specified-to-output-a-log + total-number-of-units-subject-to-commands-that-operate-units-and-have-been-specified-to-output-a-log x 2) }

/ 1,024

After calculating values with the formulae in this table, find the total of the values obtained.

When no is specified in the environment setting parameter AJSLOGOUTPUTEXTEND

Size of the scheduler log file for one day (units: kilobytes) = A + B + C + D + E

When yes is specified in the environment setting parameter AJSLOGOUTPUTEXTEND

Size of the scheduler log file for one day (units: kilobytes) = A + B + C + (D x 1.5) + E

When log data is to be output for each host, calculate the above formula for each scheduler service, and then add up the results to find the total daily volume of log data. If necessary, multiply this by the number of days that you want to keep the log. Set a value a little larger than the estimate.

(2) Example scheduler log file estimate

In this example the scheduler logs for five days are saved in a single file.

Table 3‒15: Example scheduler log file estimate

Condition

Example estimation formula

Setting for the environment setting parameter AJSLOG

all

Scheduler service start count

1

Scheduler service end count

1

A (kilobytes)=

80 x (1 + 1) / 1,024 = approx. 0.16

Setting for the environment setting parameter NETLOG

all

Maximum length of jobnet name

40 bytes

Start count for jobnets executed during one day

1,000

End count for jobnets executed during one day

1,000

Number of jobnets with a hold setting

10

Number of jobnets for which start or end delay monitoring is set

20

B (kilobytes) =

{ (90 + 40) x (1,000 + 1,000 + 10 + 20) } / 1,024 = approx. 258

Setting for the environment setting parameter JOBLOG

all

Maximum length of job name

50 bytes

Maximum length of job execution destination host name

10 bytes

Start count for the number of jobs executed during one day

3,000

End count for the number of jobs executed during one day

3,000

Number of jobs with a hold setting

30

C (kilobytes) =

{ (120 + 50 + 10) x (3,000 + 3,000 + 30) } / 1,024 = approx. 1,060

Setting for the environment setting parameter OPELOG or REFLOG

all

Maximum length of names of JP1 users that execute commands

10 bytes

Length of logical host name

11 bytes

Length of options specified for commands that operate units (ajschange, ajsplan, etc.) and are output to a log

300 bytes

Total execution count of commands that operate units and are specified for output to a log

200

Total number of units subject to commands that operate units and are specified for output to a log

50

D (kilobytes) =

{ (100 + 10 + 11 + 300) x (200 + 50) } / 1,024 = approx. 103

Setting for the environment setting parameter INFOLOG

all

Maximum length of names of JP1 users that execute commands

10 bytes

Length of logical host name

11 bytes

Length of options specified for commands that operate units (ajschange, ajsplan, etc.) and are output to a log

300 bytes

Total execution count of commands that operate units and are specified for output to a log

200

Total number of units subject to commands that operate units and are specified for output to a log

50

E (kilobytes) =

{ (100 + 10 + 11 + 300) x (200 + 50 x 2) } / 1,024= approx. 123

Scheduler log file capacity for one day (units: kilobytes) =

A + B + C + D + E = 1,544 kilobytes

Size of scheduler log file capacity for 6 days (units: kilobytes) =

1,544 x 6 days = approximately 9,264 kilobytes

The initial size of a scheduler log file is 10,240 kilobytes. Two files are stored. When one week is six business days and the size of a scheduler log file is the initial size, for operation using the example estimates, one file can hold a week's worth of log data.

If the unit you have set for outputting log data is hosts, estimate the sizes of the scheduler log files for all the configured scheduler services for each physical host or logical host, and total the estimates. The result is the estimate for one day.

(3) Expanding the scheduler log file size

To expand the size of the scheduler log file, use the jajs_config command. In the environment setting parameter LOGSIZE (if outputting log files per scheduler service) or HOSTLOGSIZE (if outputting log files per host), set the value you calculated as described in (1) Formula for estimating scheduler log file size.

For details about the environment setting parameters, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

3.4.2 Estimating the size of the scheduler trace log file

This subsection explains how to estimate the size of the scheduler trace log file.

There are two types of scheduler trace logs, and the following trace information is output to the log files:

Common scheduler trace log

Scheduler trace information about operations and command execution from JP1/AJS3 - View and about monitoring of scheduler service processes

Scheduler trace log of each scheduler service

Scheduler trace information about job execution by the scheduler service

Common scheduler trace logs are output to the file specified in the TRACELOGFILE environment setting parameter.

The file to which the scheduler trace log of each scheduler service varies depending on the setting of the TRACELOGDIV environment setting parameter.

When yes is set for the TRACELOGDIV environment setting parameter

The scheduler trace log of each scheduler service is output to the file tracelog_scheduler-service-name under the directory specified in the TRACEDIVDIR environment setting parameter.

When no is set for the TRACELOGDIV environment setting parameter

The scheduler trace log of each scheduler service is output together with common scheduler trace logs to the file specified in the TRACELOGFILE environment setting parameter.

For details about this environment parameter, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

By default, the size of each scheduler trace log file is set to 20 megabytes (20,480 kilobytes). This size of file can store the trace logs for the execution of about 2,000 jobs.

The required size of a scheduler trace log file is largely different depending on the jobnet structure, number of connections to JP1/AJS3 - View, and operation details. Also the log output destination varies depending on the setting of the TRACELOGDIV environment setting parameter. Estimate the required size of each scheduler trace log file as described next, and increase the size as needed.

Note that you can increase the size of the scheduler trace log file with the ajstrsetsz command. For details, see ajstrsetsz in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(1) When yes is set for the TRACELOGDIV environment setting parameter

If yes is set for the TRACELOGDIV environment setting parameter, estimate the file size as follows:

Common scheduler trace log

Appropriate trace log file capacity (units: kilobytes) = 3,072 x (number-of-jobs-executed-per-day#1 / 1,000) x number-of-scheduler-services x 1.5 x number-of-days-to-save-trace-logs#2

Scheduler trace log of each scheduler service (per scheduler service)#3

Appropriate trace log file capacity (units: kilobytes) = 3,072 x number-of-jobs-executed-per-day / 500 x 1.5 x number-of-days-to-save-trace-logs#2

#1

Refers to operations performed on units by commands or from JP1/AJS3 - View.

#2

Specify the number of days from the occurrence of the error to the collection of data.

#3

Estimate the file size for each scheduler service.

Example: Saving the trace log for one day (only for a physical host with one scheduler service)

3,000 jobs are executed per day.

500 hold-release and other commands are executed per day.

Appropriate trace log file capacity (size of the file specified in the TRACELOGFILE environment setting parameter)

3,072 x ( 500 / 1,000) x 1 x 1.5 x 1 = 2,304 kilobytes

Appropriate trace log file capacity (size of the file created under the directory specified in the TRACELOGDIVDIR environment setting parameter)

3,072 x 3,000 / 500 x 1.5 x 1 = 27,648 kilobytes

(2) When no is set for the TRACELOGDIV environment setting parameter

The appropriate capacity of trace log file is the sum of the size estimated for the common scheduler trace log and the size estimated for the scheduler trace log of each scheduler service. The two estimations are described in (1) When yes is set for the TRACELOGDIV environment setting parameter.

Example: Saving the trace log for one day (only for a physical host with one scheduler service)

3,000 jobs are executed per day.

500 hold-release and other commands are executed per day.

Common scheduler trace log:

3,072 x (500 / 1,000) x 1 x 1.5 x 1 = 2,304 kilobytes

Scheduler trace log of each scheduler service:

3,072 x 3,000 / 500 x 1.5 x 1 = 27,648 kilobytes

Appropriate capacity of the trace log file (size of the file specified in the TRACELOGFILE environment setting parameter):

2,304 + 27,648 = 29,952 kilobytes

3.4.3 Estimating the size of the log information output by event jobs

When you use event jobs, the size of the log output depends on the nature of the operation, including the number of event jobs executed and the number of satisfactions of monitoring conditions. As a guide, keep a log for at least 24 hours. You should estimate in advance a rough value for an output log size that will enable you to keep a log for 1 to 3 days, based on considerations like the number of event jobs executed.

Decide the size of the event log together with the number of log files. Define the estimated value using the configuration definition file. Create a text file in the following form as the log setting configuration definition file for event jobs.

[definition-key]
"environment-setting-parameter" = definition-details
"environment-setting-parameter" = definition-details
   :

We will now explain the environment setting parameters of the log setting configuration definition file for event jobs. Then we will explain the formulae used to calculate rough values for the sizes of the logs set for each process.

For details on the default disk capacity and maximum disk area used, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

For details on the procedure for changing the event job log settings, see the following references.

In Windows:

6.3.1 Changing the settings related to the size of the log for event jobs to match operational requirements in the JP1/Automatic Job Management System 3 Configuration Guide

In UNIX:

15.3.1 Changing the settings related to the size of the log for event jobs to match operational requirements in the JP1/Automatic Job Management System 3 Configuration Guide

(1) Log setting configuration definition parameters for event jobs

The following table shows the environment setting parameters.

Table 3‒16: List of log setting configuration definition parameters for event jobs

Definition Key

Environment setting parameter

Definition details

For scheduler service (common)

[{JP1_DEFAULT|logical-host-name}\JP1AJS2\SCHEDULER\EV\MANAGER\LOG]

For scheduler service (individual)

[{JP1_DEFAULT| logical-host-name}\JP1AJSMANAGER\ scheduler-service-name \EV\MANAGER\LOG]

"LogSize"=

Log size

(Common to all event job managers)

"LogNumFiles"=

Number of log files

(Common to all event job managers)

"LogSize_jpomanager"=

Log size

(Applies to individual event job manager processes)

"LogSize_jpomgrsub"=

"LogNumFiles_jpomanager"=

Number of log files

(Applies to individual event job manager processes)

"LogNumFiles_jpomgrsub"=

[{JP1_DEFAULT|logical-host-name}\JP1AOMAGENT\LOG]

"LogSize"=

Log size

(Common to all event job agents)

"LogNumFiles"=

Number of log files

(Common to all event job agents)

"LogSize_jpoagent"=

Log size

(Common to all event job agents)

"LogSize_jpoagtsub"=

"LogSize_jpocwtflMain"=

"LogSize_jpoeventwatch"=

"LogSize_jpoevsearch"=

"LogSize_jpocwttmMain"=

"LogSize_jpocwtmlmain"=

"LogSize_jpomldsk"=

"LogSize_jpomlsrv"=

"LogSize_jpomlapisend"=

"LogSize_jpomlapisend2"=

"LogSize_jpomlapirec"=

"LogSize_jpomlapirec2"=

"LogSize_jpomailrecv"=

"LogNumFiles_jpoagent"=

Number of log files

(Applies to individual processes at event job agents)

"LogNumFiles_jpoagtsub"=

"LogNumFiles_jpocwtflMain"=

"LogNumFiles_jpoeventwatch"=

"LogNumFiles_jpoevsearch"=

"LogNumFiles_jpocwttmMain"=

"LogNumFiles_jpocwtmlmain"=

"LogNumFiles_jpomldsk"=

"LogNumFiles_jpomlsrv"=

"LogNumFiles_jpomlapisend"=

"LogNumFiles_jpomlapisend2"=

"LogNumFiles_jpomlapirec"=

"LogNumFiles_jpomlapirec2"=

"LogNumFiles_jpomailrecv"=

Details on each item in the table are given below.

"LogSize"=dword:log-size

Specify the size of one log file in byte units, in hexadecimal. Make the setting within the range 20,000 (128 kilobytes) to 40,000,000 (1 gigabyte).

The value specified here affects all event job manager processes or agent processes.

"LogNumFiles"=dword:number-of-log-files

Specify the file count that triggers a log wrap (number of log files) in hexadecimal. Make the setting within the range 2 to 10 (in decimal form, 2 to 16).

The value specified here affects all event job manager processes or agent processes.

"LogSize_process name"=dword:log-size

Specify the size (in bytes, hexadecimal) of one log file when you want to change the log size for any single process at an event manager or agent. Make the setting within the range 20,000 (128 kilobytes) to 40,000,000 (1 gigabyte).

For details on the log sizes (rough values) set for each process, see (2) Calculating the log size for each process below.

"LogNumFiles_process name"=dword:number-of-log-files

Specify the number of log files, in hexadecimal, when you want to change this number for any single process at an event manager or agent. Make the setting within the range 2 to 10 (in decimal form, 2 to 16).

When each event job process starts, the log size and number of files are determined according to the following order of priority.

Specification for each process

Value specified for LogSize_process-name or LogNumFiles_process-name

Event job common specification

Value specified for LogSize or LogNumFiles

Default values for each process

Process-specific default values like those shown in the table below

Table 3‒17: Default values for event job processes and logs

Type

Process name

Platform

Default values for logs

(values in parentheses are set at JP1/AJS3 installation and setup)

Windows

UNIX

Log size

Number of log files

Manager

jpomanager

E

E

640 kilobytes

(4,096 kilobytes)

8

(13)

jpomgrsub

E

E

640 kilobytes

(3,072 kilobytes)

6

(8)

Agent

jpoagent

E

E

384 kilobytes

(3,072 kilobytes)

8

(8)

jpoagtsub

E

E

384 kilobytes

(2,048 kilobytes)

8

(16)

jpocwtflMain

E

E

1,280 kilobytes

(2,048 kilobytes)

6

(13)

jpoeventwatch

E

E

640 kilobytes

(9,216 kilobytes)

4

(8)

jpocwttmMain

E

E

128 kilobytes

(256 kilobytes)

2

(6)

jpocwtmlmain

E

E

128 kilobytes

(128 kilobytes)

2

(2)

jpoevsearch

E

E

jpomldsk

E

--

jpomlsrv

E

--

jpomlapisend

E

--

jpomlapisend2

E

--

jpomlapirec

E

--

jpomlapirec2

E

--

jpomailrecv

--

E

Legend:

E: Process exists

--: No process

The filenames of event job logs are decided as follows.

process-name[1|2|3|...].log

The filenames of event job logs are decided as follows.

jpoagent1.log
jpoagent2.log
     :
jpoagent8.log

For details about log types, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(2) Calculating the log size for each process

The calculations to determine rough values for the log size to set for each process are shown in the following table.

The values determined with these calculation formulae are for guidance only. They could change depending on the operating environment and other factors.

Table 3‒18: Log size (rough values) for each event job process

Process name

Calculation formulae (units: bytes)

jpomanager

See Table 3-19.

jpomgrsub

See Table 3-19.

jpoagent

See Table 3-20.

jpoagtsub

See Table 3-20.

jpocwtflMain

See Table 3-21.

jpoeventwatch

number-of-executions-of-JP1-event-reception-monitoring-job x 4,000

number-of-JP1-events-that-occur-on-logical-host-running-JP1/AJS3 x 1,200

number-of-monitoring-conditions-established-for-JP1-event-reception-monitoring-job x 3,800

number-of-monitoring-conditions-established-for-JP1-event-reception-monitoring-job x (number-of-macro-variables x (macro-variable-size + macro-variable-data-size (the upper limit is 1,024)))

jpoevsearch

number-of-executions-of-a-JP1-event-reception-monitoring-job-using-the-event-search-functionality-before-execution x 700

jpocwttmMain

See Table 3-22.

jpocwtmlmain

(Windows only)

Only created when using mail system linkage for Windows.

number-of-satisfactions-of-email-reception-monitoring-job-monitoring-conditions x 2,800

jpocwtmlmain

(UNIX only)

Only created when using mail system linkage for UNIX.

number-of-satisfactions-of-email-reception-monitoring-job-monitoring-conditions x 7,400

jpomldsk

Only created when using mail system linkage (on a desktop) for Windows.

(number-of-executions-of-email-sending-jobs x 200) + (each-mail-monitoring-interval x 400)

jpomlsrv

Only created when using mail system linkage (at a service) for Windows.

(number-of-satisfactions-of-email-reception-monitoring-job-monitoring-conditions x 400) + (number-of-executions-of-email-sending-jobs x 200)

jpomlapisend#1

Only created when using mail system linkage for Windows.

Number-of-executed-email-sending-jobs x 2,800

jpomlapisend2#2

Only created when using mail system linkage for Windows.

Number-of-executed-email-sending-jobs x 2,800

jpomlapirec#1

Only created when using mail system linkage for Windows.

2,800 (if email reception monitoring jobs are executed, once per monitoring interval)

jpomlapirec2#2

Only created when using mail system linkage for Windows.

2,800 (if email reception monitoring jobs are executed, once per monitoring interval)

jpomailrecv

Only created when using mail system linkage for UNIX.

number-of-mails-that-reach-the-mail-server x 1,200

#1

When the mail system linkage function is used in the JP1/AJS3 Mail service

#2

When the mail system linkage function is used on the desktop

Table 3‒19: Manager log output size

Phenomenon

Calculation formula (units: bytes)

jpomanager

jpomgrsub

Event job

Registration

3,350

2,300

Occurrence

1,900

1,550

Start condition

Registration

1,150 + (2,600 x number-of-events-in-the-start-condition#)

750 + (750 x number-of-events-in-the-start-condition#)

Occurrence

Start condition not satisfied

3,400

2,250

Start condition satisfied

3,850

2,250

#

The number of events in the start condition is the number of event jobs defined within the start condition.

Table 3‒20: Agent log output size (per job)

Phenomenon

Calculation formula

jpoagent

jpoagtsub

Event job

Registration

2,104

1,285

Occurrence

735

1,356

Start condition

Occurrence

2,104

1,285

Start condition satisfaction

735

1,356

Table 3‒21: File monitoring log output size (per job)

Phenomenon

Calculation formula (units: bytes)

When you specify the full name of the monitored file

When you specify a wildcard (*)

Event job

Registration

3,300

5,000

Event occurrence

4,500 + (macro-variable-size + macro-variable-data-size (the upper limit is 1,024))

4,500 + (macro-variable-size + macro-variable-data-size (the upper limit is 1,024))

Start condition

Registration

3,300

5,000

Event occurrence

2,800 + (macro-variable-size + macro-variable-data-size (the upper limit is 1,024))

(2,800 + (macro-variable-size + macro-variable-data-size (the upper limit is 1,024))) x number-of-event-occurrences

End

1,000

1,000

Table 3‒22: Execution interval control log output size (per job)

Phenomenon

Calculation formula (units: bytes)

Event job

Registration

2,600

Event occurrence

2,300

Start condition

Registration

2,600

Event occurrence

2,300 x number-of-event-occurrences

End

1,000

When a time-out period is specified for an event job#

Registration

1,200

Event occurrence

2,300

#

If a time-out period is set for each event job including execution interval control jobs, a log of the values indicated above is output to the execution interval control log.

(3) Estimating the log size of email sending jobs that do not use Outlook

The following table lists the environment setting parameter used to change the log size of email sending jobs that do not use Outlook:

Table 3‒23: Environment setting parameter that defines log settings for email sending jobs that do not use Outlook

Definition key

Environment setting parameter

Definition

[{JP1_DEFAULT|logical-host-name}\JP1AOMAGENT\mail_link]#

"LogSize_EmbeddedMail"=

Log size

(Applies to individual profiles)

#

Specify JP1_DEFAULT for the physical host. For logical-host-name, specify the name of a logical host.

The following describes each of the environment setting parameters:

"LogSize_EmbeddedMail"=dword:log-size

Specify the size of one log file in byte units, in hexadecimal. Make the setting within the range 80000 (512 kilobytes) to 9C3C00 (9,999 kilobytes).

The value specified for this environment setting parameter affects all of the log information of the email sending jobs that do not use Outlook.

The following table lists the formula for calculating the (estimated) log size of email sending jobs that do not use Outlook. Note that the value obtained by the formula is an approximation, and can vary depending on operating environment or other factors.

Table 3‒24: Log size (estimated value) of email sending jobs that do not use Outlook

Job name

Calculation formula (units: bytes)

Send mail job

Created only when email sending jobs that do not use Outlook are used.

number-of-executions-of-send-mail-job x 3,500

(4) Changing the size of the common log for events and actions

To change the size of the common log for events and actions:

Create a size specification file (jpocommonerr.dat) for the common log for events and actions.

The save location is as follows:

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log\jpocommonerr.dat

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

In Windows, if the installation folder is other than the above:

JP1/AJS3 - Manager:

JP1/AJS3-Manager-installation-folder\log\jpocommonerr.dat

JP1/AJS3 - Agent:

JP1/AJS3-Agent -installation-folder\log\jpocommonerr.dat

In UNIX:

/var/opt/jp1ajs2/log/jpocommonerr.dat

Define the log size in the size specification file (jpocommonerr.dat) for the common log for events and actions.

In the size specification file (jpocommonerr.dat) for the common log for events and actions, specify the log size according to the following format. The specified log size will be applied immediately.

LogSize: log-size

Specify the log size, in bytes, in decimal format between 8,388,608 and 2,147,483,647. If a value less than the lower limit (8,388,608 bytes) is specified, the default value (8,388,608 bytes) is used. If a value more than the upper limit (2,147,483,647 bytes) is specified, the upper limit (2,147,483,647 bytes) is used.

The following is an example for the common log for events and actions, for when the log size is 16,384 kilobytes.

LogSize: 16777216

Note that even in a cluster configuration, since the common log for events and actions is output to the log files on the physical hosts, you must set the size on both physical hosts. To revert the size setting to the default (8,192 kilobytes), delete the size specification file (jpocommonerr.dat). The changes will be applied immediately.

The following table shows formulas for estimating the output size of the common log for events and actions.

Table 3‒25: Output size of the common log for events and actions (per processing item)

Phenomenon

Calculation formula (units: bytes)

Event job

Registration

1,024

Event occurrence

512

Forced termination

1,024

Start condition

Registration

(3 + number-of-event-jobs-defined-in-the-start-condition x 2) x 512

Start condition formation

For AND:

( 4 + number-of-event-jobs-defined-in-the-start-condition x 2) x 512

For OR:

4,096

Forced termination

2,048

JP1/AJS3 start and stop

Manager host restart

(number-of-scheduler-services + number-of-jobnets-with-all-start-conditions-being-registered x 6 + number-of-all-event-jobs-being-registered x 2) x 512

Action job

Registration

1,024

Note

Even in a cluster configuration, output is performed to the default directory. As a result, for the output size of the common log for events and actions, use the sum of the values above for both the logical host and physical host.

3.4.4 Estimating the size of log files for JP1/AJS3 - View

This subsection explains how to estimate the size of log files that are output by JP1/AJS3 - View.

The following log files for JP1/AJS3 - View are explained here:

Storage location

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2V\log\ajs2view#nnnn_{1|2}.log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

When you start multiple instances of JP1/AJS3 - View, a value between 0001 and 9999 is assigned to nnnn of #nnnn_. If you do not start multiple instances of JP1/AJS3 - View, #nnnn_ is omitted.

Size

You can specify a size from 1 to 512 in megabytes (the default is 1 megabyte).

To change the log file size, open the Preferences dialog box of JP1/AJS3 - View, click the Other tab, and use Max. log file size.

The required log file size depends on the trace level, operation details, and errors. The following tables show the guidelines for estimating the log file size when the trace level is 3 (default).

Add one megabyte for estimation because re-connections might be required when JP1/AJS3 - Manager is disconnected or more operations might fail than you expect.

Table 3‒26: Estimating the log file size for JP1/AJS3 - View

Item

Log size (units: kilobytes)

Starting JP1/AJS3 - View

10

Ending JP1/AJS3 - View

10

Table 3‒27: Estimating the log file size for windows (common)

Item

Log size (units: kilobytes)

Operations#

3 x n

Operation failures

4 x m

Legend:

n: Number of operations

m: Number of operation failures

#

Indicates menu operations and closing or opening dialog boxes. Operations also include the creation of new units and changing of icon positions in the Jobnet Editor window.

When you operate multiple units simultaneously, estimate the log file size in the same manner you estimate the log file size when you operate units individually.

Table 3‒28: Estimating the log file size for each window

Window

Log size per operation (units: kilobytes)

View

Refresh

Automatic update

Selecting a tree node#1

JP1/AJS3 - View (Main window)

3 + 2 x a

2

2

2

JP1/AJS3 - View (Summary Monitor window)

5 x b

5 x b

5 x b

--

Jobnet Editor

4 + 0.5 x (c - 1 ) +5 x a

2

--

5

Jobnet Monitor

5 + 0.5 x (c - 1) + 4 x a

3 + 0.5 x d + 0.5 x e

1 + 0.5 x d + 0.5 x e

4

Monthly Schedule

5 + 0.5 x (c - 1) + f

2 + f

--

1

Daily Schedule#2

4 + 0.5 x (c - 1) + f

2 + f

2 + f

1

Calendar#3

5

3

--

--

Search

0.5

--

--

--

Legend:

a:

Number of the hierarchy level of the first unit to be selected in the tree area in the displayed window

The level of the root is 0.

b:

Number of units to be monitored

c:

Number of the hierarchy level of the unit for which the window is displayed

d:

Number of Monitor Details dialog boxes to be displayed

e:

Number of Execution Result Details dialog boxes to be displayed

f:

Number of target root jobnets, or the number of root jobnets immediately under the target job group when 1 is displayed for the root jobnet

--:

Not applicable

#1

Indicates the selection or expansion of a unit in the tree area.

#2

Indicates the Daily Schedule (Hierarchy) window or the Daily Schedule (All Jobs) window.

#3

Indicates the Edit Monthly Calendar window or the Edit Annual Calendar window.

Examples:

To estimate the log file size required to keep a one-week log, use the following conditions:

The period that JP1/AJS3 - View runs to monitor tasks is one week.

The JP1/AJS3 - View window is automatically update every 300 seconds.

The Daily Schedule (Hierarchy) window for the job groups (including 10 root jobnets below) in the root job group is displayed and automatically updated every 300 seconds.

One operation is performed per hour.

The rate of operation failure is 0.1.

The required log file size is as follows:

For starting or ending JP1/AJS3 - View

20 kilobytes

For menu operations

3 x 24 x 7 = 504 kilobytes

For operation failures

4 x 24 x 7 / 10 = 68 kilobytes

For displaying the JP1/AJS3 - View window

3 kilobytes

For automatic update in the JP1/AJS3 - View window

2 x 3,600 x 24 x 7 / 300 = 4,032

For displaying the Daily Schedule (Hierarchy) window

4 + 0.5 x (1 - 1) + 10 = 14

For automatic update in the Daily Schedule (Hierarchy) window

(2 + 10) x 3,600 x 24 x 7 / 300 = 24,192

Total

20 + 504 + 68 + 3 + 4,032 + 14 + 24,192 = 28,833 (kilobytes) = 28.1 (megabytes)

When you round the above number and add 1 megabyte for leeway, the result is 30 megabytes.

3.4.5 Estimating the size of the logs output by execution

The number of the jobs except for queueless jobs and event jobs executed per days are less than 10,000. You do not need to estimate log size of job execution environment, you can use the default.

If the jobs except for queueless jobs and event jobs executed per days exceed 10,000, estimate log size.

Determine both the size and number of log files for each type of log. Then define the values you have estimated using the jajs_config command.

Execute following command and set for environment setting parameter, explained in (1) Environment setting parameters in the log configuration definition for the execution environment of QUEUE jobs and submit jobs, then restart JP1/AJS3.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents
["environment setting parameter-name-2"=definition-contents-2]

Only one definition key can be specified in definition-key-name. If you want to set environment setting parameter different in a definition keys, you must execute the jajs_config command for each definition key.

Supplementary notes

If you set more than one environment setting parameter different in definition key at the same time, you can use jbssetcnf command. For details about jbssetcnf command, see the explanation for jbssetcnf command in the JP1/Base User's Guide.

If you use jajs_config command, environment setting parameter name and definition are checked, but if you use jbssetcnf command, they do not be checked. We recommend using the jajs_config command to prevent the wrong contents being set.

Estimate the environment setting parameter as which a definition key can be set every scheduler service by the number of the jobs except for queueless jobs and event jobs by each scheduler service.

The following explains the environment setting parameters that you set in the log configuration definition file for the execution environment, and gives a rough guide to the log sizes you will need to set.

For details about the default disk space requirements and maximum disk space used, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(1) Environment setting parameters in the log configuration definition for the execution environment of QUEUE jobs and submit jobs

The following table lists the environment setting parameters.

Table 3‒29: Environment setting parameters in the log configuration definition for the execution environment

Log file name

Definition key

Environment setting parameter

Definition contents

Job execution manager log

jpqmanexec{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log#1

In scheduler service (common):

[{JP1_DEFAULT|logical-host-name}\JP1AJS2\SCHEDULER\QUEUE\MANAGER\Log]

In scheduler service (different):

[{JP1_DEFAULT|logical-host-name}\JP1AJSMANAGER\scheduler-service-name\QUEUE\MANAGER\Log]

In submit jobs:

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Log]

"ExecLogFileSize"=dword:size

"ExecLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 8,000 (in decimal form, 512 to 32,768).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 10 (in decimal form, 2 to 16).

Job execution agent log

jpqagtexec{1|2|3|4|5|6|7|8}.log#2

jpqagtexeccld{1|2|3|4|5|6|7|8}.log

jpqagtexecdmn{1|2|3|4|5|6|7|8}.log

jpqagtexecmon{1|2|3|4|5|6|7|8}.log#3

[{JP1_DEFAULT|logical-host-name}\JP1NBQAGENT\Log]

"ExecLogFileSize"=dword:size

"ExecLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 8,000 (in decimal form, 512 to 32,768).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 10 (in decimal form, 2 to 16).

Job execution internal log

jpqagt_{00|01|02|03|04|05|06|07}.log

jpqmon_{00|01|02|03|04|05|06|07}.log

jpqnjpagt_{00|01|02|03|04|05|06|07}.log

[{JP1_DEFAULT|logical-host-name}\JP1NBQAGENT\Log]

"TraceLogFileSize"=dword:size

"TraceLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 1,000 (in decimal form, 512 to 4,096).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 100 (in decimal form, 2 to 256).

Job execution internal log

jpqnjpdata_{00|01}.log

"extTraceLogFileSize"=dword:size

"extTraceLogFileCount"=dword:number-of-files

Job execution internal log

jpqclient_{00|01|02|03|04|05|06|07|08|09}.log

jpqclientnjp_{00|01|02|03|04|05|06|07|08|09}.log

[{JP1_DEFAULT|logical-host-name}\JP1NBQCLIENT\Log]

"TraceLogFileSize"=dword:size

"TraceLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 1,000 (in decimal form, 512 to 4,096).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 100 (in decimal form, 2 to 256).

Job execution internal log

jpqnjpdata_{00|01}.log

"extTraceLogFileSize"=dword:size

"extTraceLogFileCount"=dword:number-of-files

Job execution internal log

jpqman_{00|01|02|03}.log

jpqmandb_{00|01|02|03}.log

jpqmannjp_{00|01|02|03}.log

In scheduler service (common):

[{JP1_DEFAULT|logical-host-name}\JP1AJS2\SCHEDULER\QUEUE\MANAGER\Log]

In scheduler service (different):

[{JP1_DEFAULT|logical-host-name}\JP1AJSMANAGER\scheduler-service-name\QUEUE\MANAGER\Log]

In submit jobs:

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Log]

"TraceLogFileSize"=dword:size

"TraceLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 1,000 (in decimal form, 512 to 4,096).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 100 (in decimal form, 2 to 256).

Job execution internal log

jpqnjpdata_{00|01}.log

"extTraceLogFileSize"=dword:size

"extTraceLogFileCount"=dword:number-of-files

Job execution internal log

jpqnotify_{00|01}.log

jpqnotifynjp_{00|01}.log

In scheduler service (common):

[{JP1_DEFAULT|logical-host-name}\JP1AJS2\SCHEDULER\QUEUE\NOTIFY\Log]

In scheduler service (different):

[{JP1_DEFAULT|logical-host-name}\JP1AJSMANAGER\scheduler-service-name\QUEUE\NOTIFY\Log]

"TraceLogFileSize"=dword:size

"TraceLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 1,000 (in decimal form, 512 to 4,096).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 100 (in decimal form, 2 to 256).

Job execution internal log

jpqnjpdata_{00|01}.log

"extTraceLogFileSize"=dword:size

"extTraceLogFileCount"=dword:number-of-files

Job execution client log

jpqcliexec{1|2}.log#4

[{JP1_DEFAULT|logical-host-name}\JP1NBQCLIENT\Log]

"ExecLogFileSize"=dword:size

"ExecLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 8,000 (in decimal form, 512 to 32,768).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 10 (in decimal form, 2 to 16).

Job execution status report log

jpqnfyexec{1|2}.log

In scheduler service (common):

[{JP1_DEFAULT|logical-host-name}\JP1AJS2\SCHEDULER\QUEUE\NOTIFY\Log]

In scheduler service (different):

[{JP1_DEFAULT|logical-host-name}\JP1AJSMANAGER\scheduler-service-name\QUEUE\NOTIFY\Log]

"ExecLogFileSize"=dword:size"ExecLogFileCount"=dword:number-of-files

size

Specify the log file size in kilobytes. You can set 200 to 8,000 (in decimal form, 512 to 32,768).

number-of-files

Specify the number of log files before log records are wrapped around to the first file again. You can set 2 to 10 (in decimal form, 2 to 16).

#1

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqmanexec{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_man{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log

#2

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqagtexec{1|2|3|4|5|6|7|8}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_agt{1|2|3|4|5|6|7|8}.log

#3

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqagtexecmon{1|2|3|4|5|6|7|8}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_agtmon{1|2|3|4|5|6|7|8}.log

#4

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqcliexec{1|2}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_cli{1|2}.log

The logs output in the execution environment are output to the following paths:

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

%ALLUSERSPROFILE\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

In Windows, if the installation folder is other than the above:

JP1/AJS3-installation-folder\log

In UNIX:

/var/opt/jp1ajs2/log

For details about the types of logs, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(2) Guide to the size of the logs output in the execution environment for QUEUE jobs and submit jobs

The following table gives a rough guide to the log sizes to set. These sizes might vary, depending on your system environment.

Table 3‒30: Example of estimating the size of the logs output in the execution environment for QUEUE jobs and submit jobs

Log file name

Log size output per job (bytes)

Log size output per 10,000 jobs (bytes)

Calculation of the number of log files required to execute 10,000 jobs#1

Log capacity required to execute 10,000 jobs

jpqmanexec{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log#2, #3

400

3,997,696

4,800 KB / 1,024 KB

1,024 KB x 5 files

jpqagtexec{1|2|3|4|5|6|7|8}.log#4

277

2,768,896

3,300 KB / 512 KB

512 KB x 7 files

jpqagtexeccld{1|2|3|4|5|6|7|8}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqagtexecdmn{1|2|3|4|5|6|7|8}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqagtexecmon{1|2|3|4|5|6|7|8}.log#5

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqagt_{00|01|02|03|04|05|06|07}.log

330

3,302,400

4,000 KB / 512 KB

512 KB x 8 files

jpqmon_{00|01|02|03|04|05|06|07}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqnjpagt_{00|01|02|03|04|05|06|07}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqnjpdata_{00|01}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqclient_{00|01|02|03|04|05|06|07|08|09}.log

2,000

20,000,000

23,500 KB / 1,024 KB

1,024 KB x 23 files

jpqclientnjp_{00|01|02|03|04|05|06|07|08|09}.log

2

16,384

20 KB / 1,024 KB

1,024 KB x 1 file

jpqnjpdata_{00|01}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqman_{00|01|02|03}.log#2

400

4,000,000

4,700 KB / 512 KB

512 KB x 10 file

jpqmandb_{00|01|02|03}.log#2

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqmannjp_{00|01|02|03}.log#2

500

5,000,000

5,900 KB / 512 KB

512 KB x 12 files

jpqnjpdata_{00|01}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqnotify_{00|01}.log#2

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqnotifynjp_{00|01}.log#2

130

1,300,000

1,600 KB / 512 KB

512 KB x 4 files

jpqnjpdata_{00|01}.log#2

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqcliexec{1|2}.log#6

2

16,384

20 KB / 512 KB

512 KB x 1 file

jpqnfyexec{1|2}.log

2

16,384

20 KB / 512 KB

512 KB x 1 file

#1

Calculate a value with some leeway.

#2

This is not used with JP1/AJS3 - Agent, so no increase is necessary.

#3

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqmanexec{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_man{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15}.log

#4

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqagtexec{1|2|3|4|5|6|7|8}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_agt{1|2|3|4|5|6|7|8}.log

#5

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqagtexecmon{1|2|3|4|5|6|7|8}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_agtmon{1|2|3|4|5|6|7|8}.log

#6

In a cluster system in Windows, the name of the job execution manager log file varies as follows depending on how JP1/AJS3 is installed:

If JP1/AJS3 09-00 or later is installed as a new installation:

jpqcliexec{1|2}.log

If JP1/AJS3 is installed as an upgrade installation from JP1/AJS2:

If logical hosts have been configured before the upgrade installation, the file names used with JP1/AJS2 are inherited as the log file names in the cluster system.

jpqExecLog_cli{1|2}.log

3.4.6 Estimating the size of log files output by a flow control subprocess

A flow control subprocess outputs log files in an environment in which wait conditions are used. You do not need to estimate the log file size for an environment in which wait conditions are not used. For details about using wait conditions, see 6.1.8 Settings for using wait conditions in the JP1/Automatic Job Management System 3 Configuration Guide.

A flow control subprocess outputs two log files for each scheduler service. The default size of one file is 10,240 kilobytes.

The size of log data differs greatly depending on the execution count for units with wait conditions and the number of units whose end is being waited for. You should estimate an appropriate size for the log file so that logs for the number of days from the occurrence of an error to the collection of data can be saved.

(1) Formula for estimating the size of log files output by a flow control subprocess

The following table describes the variables required for estimating the size of log files output by a flow control subprocess.

Table 3‒31: Variables required for estimating the size of log files output by a flow control subprocess

Variable

Description

a

Number of units with wait conditions executed per day#

b

Total number of waits per day

c

Size of the full name of the unit (units: bytes)

d

Number of units executed per day whose end is being waited for#

e

Number of temporary change operations performed for wait conditions per day

f

Number of root jobnets executed per day in a scheduler service that has units with wait conditions#

#

If a unit is executed more than once per day, multiply the value by the execution count.

To estimate the log file size, replace these variables in the following formula with values:

Log file size output by a flow control subprocess (units: kilobytes) =

{300 + (a x 7 + b x 4 + d x 3 + e x 3 + f x 3) x (300 + c x 2)} / 1,024

For logs that are to be kept for more than one day, multiply the estimated log file size by the number of days the logs are to be kept. Because a maximum of two log files are output, if you want to estimate the size for one file, divide the result by two.

(2) Example of estimating the size of log files output by a flow control subprocess

The following describes an example of estimating the size of log files output by a flow control subprocess.

The example uses the following values for the variables required to estimate the size.

Table 3‒32: Variable values required for estimating the size of log files output by a flow control subprocess

Variable

Variable value

Description

a

300

300 units with wait conditions are executed per day (each unit is executed only once).

b

300

Waiting occurs 300 times per day.

c

50

The full unit name is specified with 50 bytes.

d

300

300 units whose ends are being waited for are executed per day (each unit is executed only once).

e

30

The temporary change operation for wait conditions is performed 30 times per day.

f

100

100 root jobnets are executed per day in a scheduler service that has units with wait conditions (each root jobnet is executed only once).

The formula for this example is as follows:

Log file size output by a flow control subprocess (units: kilobytes) =

{300 + (300 x 7 + 300 x 4 + 300 x 3 + 30 x 3 + 100 x 3) x (300 + 50 x 2)} / 1,024

= 1,794 (rounded up)

To keep this log data for ten days, you can estimate the size of one log file as follows:

1,794 x 10 days / 2 = 8,970 (units: kilobytes)

(3) Expanding the size of log files output by a flow control subprocess

If the file size you estimated in (1) Formula for estimating the size of log files output by a flow control subprocess is greater than the default (10,240 kilobytes), you need to increase the log file size. To do so, execute the jajs_config command to set the FLBDLOGSIZE environment setting parameter to a value slightly greater than the estimated value.

For details about the environment setting parameters, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

3.4.7 Estimating the size of log files for Web Console server

This subsection explains how to estimate the size of log files that are output by JP1/AJS3 - Web Console.

This subsection covers the following JP1/AJS3 - Web Console log files:

Storage location

For Windows, if the installation folder is in the default folder or a folder protected by the system:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\jp1ajs3web\log\appserver{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16}.log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

For Windows in which an installation folder other than the above is used:

JP1/AJS3-Web-Console-installation-folder\log\appserver{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16}.log

In UNIX:

/var/opt/jp1ajs3web/log/appserver{1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16}.log

Size

You can specify a size from 4 to 16,384 in kilobytes (the default is 8,192 kilobytes).

You can change size of the log file in the environment-settings file.

The required log file size depends on the trace level, operation details, and errors. The table below provides guidelines for estimating the log file size when the trace level is info (default).

Add one megabyte for estimation because re-connections might be required when JP1/AJS3 - Manager is disconnected or more operations might fail than you expect.

To estimate the log file size, add the estimation result for the Web GUI and the estimation result for the API.

Table 3‒33: Estimating the log file size for each window displayed in the Web GUI

Window

Estimated log file size required per operation (units: kilobytes)

Initial display

Automatic update

Manual update

Execution registration

Define details

Change job status

Add

Change Plan

Change Delay Monitor

Others#1

Dashboard screen

(total-number-of-monitored-units#2 + 5) x 2.5

#3 (number-of-monitored-units + 3) x 2.5

(number-of-monitored-units#4 + 3) x 2.5

--

--

--

--

--

--

(number-of-monitored-units#4 + 4) x 2.5

List screen

10.0

5.0

5.0

12.0

--

--

--

--

--

7.5

Monitor dialog box#5

15.0

7.5

7.5

--

8.0

9.0

--

11.0

--

7.5

Monthly Schedule screen

99 + number-of-registrations-of-a-jobnet-definition-release#6 x 3

--

95 + number-of-registrations-of-a-jobnet-definition-releas#6 x 3

97 + number-of-registrations-of-a-jobnet-definition-releas#6 x 3

--

--

100 + number-of-registrations-of-a-jobnet-definition-releas#6 x 3

98 + number-of-registrations-of-a-jobnet-definition-releas#6 x 3

99 + number-of-registrations-of-a-jobnet-definition-releas#6 x 3

97 + number-of-registrations-of-a-jobnet-definition-releas#6 + 1) x 3

Legend:

--: Not applicable

#1

Refers to the following operations: canceling registration, specifying the hold setting, releasing the hold setting, interrupt operations, kill operations, re-execution, and getting detailed information.

#2

Total number of units specified as monitoring targets.

#3

Only the monitored units with automatic update enabled are summed up.

#4

Total number of units specified as monitoring targets being used.

#5

If you want to use the Monitor screen, be sure to add the size of the log file for the Monitor screen. The method for estimating the size of the log file for the Monitor screen is the same as the method for estimating the size of the log file for the Monitor dialog box.

#6

When displaying a root jobnet that does not have release information, the number of registrations of a jobnet-definition release is 1. When displaying a root jobnet that has release information, the number of registrations of a jobnet-definition release is the number of pieces of release information in the Being applied and Release wait statuses.

Example:

This example estimates the log file size required to keep a one-week log, assuming the following conditions:

The Web GUIs run 8 hours a day, and operations are monitored in the Dashboard screen.

In this period, 10 Web GUIs run.

The number of monitoring targets for the Dashboard screen is set to 1.

Automatic updating of the Dashboard screen is set to ON (the automatic update period is 10 minutes).

The total number of monitored units for the Dashboard screen is set to 10.

The required log file size is as follows:

Log file size required to perform initial display for an instance of Web GUI

15 x 2.5 = 37.5 kilobytes

Log file size required to perform automatic update for an instance of Web GUI

13 x 2.5 = 32.5 kilobytes

Number of automatic updates performed by Web GUI per day

6 x 8 - 1 = 47 times

Log file size for one day for one Web GUI

37.5 x 1 + 32.5 x 47 = 1,565 kilobytes

Total log file size in the period

1,565 x 10 x 7 = 109,550 kilobytes

When you round the above number and add 1 MB leeway, the result is 108 MB.

Table 3‒34: Estimating the log file size for each API

API

Log size per operation (units: kilobytes)

Acquisition of a unit list

12.0

Planned execution registration

12.0

Fixed execution registration

12.0

Immediate execution registration

12.0

Other APIs

7.5

Example:

This example estimates the log file size required to keep a one-week log, assuming the following conditions:

The statuses of operations are monitored once an hour by using the API function for acquiring a list of all units.

The number of monitored units is 5. A separate API function is issued to monitor the status of each unit.

The required log file size is as follows:

Log file size required to monitor each unit once

12 x 5 = 60 kilobytes

Log file size required for one day

60 x 24 = 1,440 kilobytes

Total log file size required for one week

1,440 x 7 = 10,080 kilobytes

Round the above number and add 1 MB for safety. The final estimate is 11 MB.

3.4.8 Estimating the size of performance log files

This subsection explains how to estimate the size of performance log files.

Performance log files are binary-format log files that are output if the performance report output function is enabled. The data recorded in performance log files can be exported to CSV files by using the ajsreport command. For details about the performance report output function, see 5.3.1 Overview of the performance report output function in the JP1/Automatic Job Management System 3 Administration Guide.

The following information is output to the performance log files:

Amount of data processed by the scheduler services

Job execution statuses

For the performance log files, the minimum period for which data is retained in performance log files can be specified by using the AJSREPORTSTOREDAYPERIOD environment setting parameter. If the scheduler service is not running or the number of jobs being run is fewer than expected, the data might be retained longer than the specified number of days. In an environment in which the ajsreport command is periodically run to output CSV files, you do not need to lengthen the data retention period. For details about the AJSREPORTSTOREDAYPERIOD setting parameter, see 20.4.2(116) AJSREPORTSTOREDAYPERIOD in the JP1/Automatic Job Management System 3 Configuration Guide.

The maximum size of performance log files is determined by the value specified for the AJSREPORTSTOREDAYPERIOD environment setting parameter. You can calculate the maximum size of performance log files by using the following formula:

The maximum size of performance log files (units: kilobytes) =

86,400 x value-of-AJSREPORTSTOREDAYPERIOD-environment-setting-parameter (units: days)

Example:

If the data in a performance log file is retained for at least 14 days, the maximum size of performance log files is as follows:

86,400 x 14 = 1,209,600 kilobytes

3.4.9 Estimating the size of job execution result log files and event job execution result log files

This section describes how to estimate the sizes of job execution result log files and event job execution result log files. This section also describes the environment setting parameters that are required to change the sizes.

(1) How to estimate the size of job execution result log files

Job execution result log files allow you to check the job execution status on the agent host in cases where the status of a job running on the manager host becomes unknown (because of a communication error, for example).

If approximately 30,000 jobs are run per day, the job execution result log files of the default size can hold approximately seven days' worth of messages.

Therefore, you do not need to estimate the size of job execution result log files if fewer than 30,000 jobs are to be run per day. This also applies if the job execution result log files are collected shortly after a failure occurs on the manager host. In these cases, you do not need to change the default size.

If more than 30,000 jobs are to be run, or if job execution result log files are collected at long intervals, we recommend that you estimate the size of job execution result log files.

The following shows the formula for estimating the size of job execution result log files:

Appropriate-job-execution-result-log-file-capacity (units: bytes) =
900# x number-of-jobs-run-per-day x number-of-days-to-save

#: Number of messages that are output per job

Example:

If 100,000 jobs are run per day and log data needs to be saved for 10 days, the required file size is as follows:

900 x 100,000 x 10 = 900,000,000 byte (878,906 kilobytes)

When determining the size of job execution result log files, you also need to consider how many files are to be retained. Then define the values you have estimated using the jajs_config command.

Run the following command to configure the environment setting parameters that are described in (2) Environment setting parameters for the job execution result log file, and then restart JP1/AJS3:

jajs_config -k definition-key-name "environment-setting-parameter-name"=definition-contents["environment-setting-parameter-name-2"=definition-contents-2]

(2) Environment setting parameters for the job execution result log file

The following table lists the environment setting parameters for the job execution result log file.

Table 3‒35: Environment setting parameters for the job execution result log file

No.

Definition key

Environment setting parameter

Definition

Target OS

Target software products

1

[{JP1_DEFAULT|logical-host-name}\JP1NBQAGENT\Log]#

"JOBEXECRESULTLOG"=

Type of message data to be output to the job execution result log file

Windows

UNIX

M, A, ME

2

"JOBEXECRESULTLOGPATH"=

Name of the directory used to store the job execution result log file

Windows

UNIX

M, A, ME

3

"JOBEXECRESULTLOGSIZE"=

The size of the job execution result log file

Windows

UNIX

M, A, ME

4

"JOBEXECRESULTLOGCOUNT"=

Number of the job execution result log files

Windows

UNIX

M, A, ME

Legend:

M: JP1/AJS3 - Manager

A: JP1/AJS3 - Agent

ME: JP1/AJS3 - Agent Minimal Edition

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

(a) JOBEXECRESULTLOG

For this parameter, specify the type of message data to be output to the job execution result log file.

Format

"JOBEXECRESULTLOG"=dword:type-of-message-data-to-be-output-to-the-job-execution-result-log-file

Specifiable values

0

Outputs no message to job execution result log files.

1

Outputs a message that contains the following items to job execution result log files:

Unit full name#

Execution ID#

Manager host name

Job Number

Process ID

Return code

End statuses

#: If the job that was run is a submit job, the value of the JP1JobName environment setting variable is output.

2

Outputs a message that contains the following items, in addition to the items that are output when 1 is specified, to job execution result log files:

Execution file names (Script file names)#

Command sentence (Only UNIX)

Parameters

JP1 user names

Run-time OS user

#: If the job that was run is an action job, HTTP connection job, or passing-information setting job, the job type is output.

Default value

0

During a new installation of JP1/AJS3, 2 is set.

Recommended value

2

When the setting takes effect

The next time the JP1/AJS3 service starts

(b) JOBEXECRESULTLOGPATH

For this parameter, specify the full path name of the directory that stores job execution result log files. This parameter takes effect if 1 or 2 is specified for the JOBEXECRESULTLOG environment setting parameter.

Format

"JOBEXECRESULTLOGPATH"="name-of-the-directory-used-to-store-the-job-execution-result-log-file"

Specifiable values

A character string of no more than 210 bytes

Default value

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

For a physical host:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

For a logical host:

shared-folder\jp1ajs2\log

In Windows, if the installation folder is other than the above:

For a physical host:

JP1/AJS3-Manager-installation-folder\log

For a logical host:

shared-folder\jp1ajs2\log

In UNIX:

For a physical host:

/var/opt/jp1ajs2/log

For a logical host:

shared-directory/jp1ajs2/log

Recommended value

Defaults

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

The jobexecresult folder is created under the folder specified by using this environment setting parameter. Job execution result log files are stored in the jobexecresult folder.

If you want to change the path, size, or number of job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

The following shows the procedure for changing the path, size, or number of job execution result log files:

Stop the JP1/AJS3 service on the target physical or logical host.

If necessary, back up the job execution result log files (ajsjobexecresult{1|2|3|...|n}.log).

For details about the folder that stores the job execution result log files, see the description of the JOBEXECRESULTLOGPATH environment setting parameter.

Delete all job execution result log files.

Delete the management file of the job execution result log files (ajsjobexecresult.mm).

The management file of the job execution result log files is stored in the mmap folder under the folder that stores the job execution result log files.

Change the value of the environment setting parameter.

Restart the JP1/AJS3 service that you stopped in step 1.

(c) JOBEXECRESULTLOGSIZE

For this parameter, specify the size of job execution result log files. This parameter takes effect if 1 or 2 is specified for the JOBEXECRESULTLOG environment setting parameter.

Format

"JOBEXECRESULTLOGSIZE"=dword:size-of-the-job-execution-result-log-file

Specifiable values

A hexadecimal value (in kilobytes) from 00000400 to 00004000 (1,024 to 16,384 in decimal)

Default value

dword:00004000 (16,384 in decimal)

Recommended value

Set the value appropriate for the operating environment.

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

If you want to change the path, size, or number of job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

For details, see Cautionary note in (b) JOBEXECRESULTLOGPATH.

(d) JOBEXECRESULTLOGCOUNT

For this parameter, specify the number of job execution result log files. This parameter takes effect if 1 or 2 is specified for the JOBEXECRESULTLOG environment setting parameter.

Format

"JOBEXECRESULTLOGCOUNT"=dword:number-of-the-job-execution-result-log-files

Specifiable values

A hexadecimal value from 00000001 to 00000040 (1 to 64 in decimal)

Default value

dword:0000000C (12 in decimal)

Recommended value

Set the value appropriate for the operating environment.

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

If you want to change the path, size, or number of job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

For details, see Cautionary note in (b) JOBEXECRESULTLOGPATH.

(3) How to estimate the size of event job execution result log files

Event job execution result log files allow you to check the event job execution status on the agent host in cases where the status of an event job running on the manager host becomes unknown (because of a communication error, for example).

If approximately 24,000 jobs are run per day, the event job execution result log files of the default size can hold approximately seven days' worth of messages.

Therefore, you do not need to estimate the size of event job execution result log files if fewer than 24,000 jobs are to be run per day. This also applies if the event job execution result log files are collected shortly after a failure occurs on the manager host. In these cases, you do not need to change the default size.

If more than 24,000 jobs are to be run, or if event job execution result log files are collected at long intervals, we recommend that you estimate the size of event job execution result log files.

The following shows the formula for estimating the size of event job execution result log files:

Appropriate-event-job-execution-result-log-file-capacity (units: bytes) =
400# x number-of-event-jobs-run-per-day x number-of-days-to-save

#: Number of messages that are output per job

Example:

If 24,000 event jobs are run per day and log data needs to be saved for 10 days, the required file size is as follows:

400 x 24,000 x 10 = 96,000,000 byte (93,750 kilobytes)

When determining the size of event job execution result log files, you also need to consider how many files are to be retained. Then define the values you have estimated using the jajs_config command.

Run the following command to configure the environment setting parameters that are described in (4) Environment setting parameters for the event job execution result log file, and then restart JP1/AJS3:

jajs_config -k definition-key-name "environment-setting-parameter-name"=definition-contents["environment-setting-parameter-name-2"=definition-contents-2]

(4) Environment setting parameters for the event job execution result log file

The following table lists the environment setting parameters for the event job execution result log file.

Table 3‒36: Environment setting parameters for the event job execution result log file

No.

Definition key

Environment setting parameter

Definition

Target OS

Target software products

1

[{JP1_DEFAULT|logical-host-name}\JP1NBQAGENT\Log]#

"EVJOBEXECRESULTLOG"=

Type of message data to be output to the event job execution result log file

Windows

UNIX

M, A, ME

2

"EVJOBEXECRESULTLOGPATH"=

Name of the directory used to store the event job execution result log file

Windows

UNIX

M, A, ME

3

"EVJOBEXECRESULTLOGSIZE"=

The size of the event job execution result log file

Windows

UNIX

M, A, ME

4

"EVJOBEXECRESULTLOGCOUNT"=

Number of the event job execution result log files

Windows

UNIX

M, A, ME

Legend:

M: JP1/AJS3 - Manager

A: JP1/AJS3 - Agent

ME: JP1/AJS3 - Agent Minimal Edition

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

(a) EVJOBEXECRESULTLOG

For this parameter, specify the type of message data to be output to the event job execution result log file.

Format

"EVJOBEXECRESULTLOG"=dword:type-of-message-data-to-be-output-to-the-event-job-execution-result-log-file

Specifiable values

0

Outputs no message to event job execution result log files.

1

Outputs a message that contains the following items to event job execution result log files:

Scheduler service name

Unit ID

Execution ID

Manager host name

Return code

End statuses

2

Outputs a message that contains the following items, in addition to the items that are output when 1 is specified, to event job execution result log files:

Job types

Default value

0

During a new installation of JP1/AJS3, 2 is set.

Recommended value

2

When the setting takes effect

The next time the JP1/AJS3 service starts

(b) EVJOBEXECRESULTLOGPATH

For this parameter, specify the full path name of the directory that stores event job execution result log files. This parameter takes effect if 1 or 2 is specified for the EVJOBEXECRESULTLOG environment setting parameter.

Format

"EVJOBEXECRESULTLOGPATH"="name-of-the-directory-used-to-store-the-event-job-execution-result-log-file"

Specifiable values

A character string of no more than 210 bytes

Default value

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

For a physical host:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

For a logical host:

shared-folder\jp1ajs2\log

In Windows, if the installation folder is other than the above:

For a physical host:

JP1/AJS3-Manager-installation-folder\log

For a logical host:

shared-folder\jp1ajs2\log

In UNIX:

For a physical host:

/var/opt/jp1ajs2/log

For a logical host:

shared-directory/jp1ajs2/log

Recommended value

Defaults

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

The evjobexecresult folder is created under the folder specified by using this environment setting parameter. Event job execution result log files are stored in the evjobexecresult folder.

If you want to change the path, size, or number of event job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

The following shows the procedure for changing the path, size, or number of event job execution result log files:

Stop the JP1/AJS3 service on the target physical or logical host.

If necessary, back up the event job execution result log files (ajsevjobexecresult{1|2|3|...|n}.log).

For details about the folder that stores the event job execution result log files, see the description of the EVJOBEXECRESULTLOGPATH environment setting parameter.

Delete all event job execution result log files.

Delete the management file of the event job execution result log files (ajsevjobexecresult.mm).

The management file of the event job execution result log files is stored in the mmap folder under the folder that stores the event job execution result log files.

Change the value of the environment setting parameter.

Restart the JP1/AJS3 service that you stopped in step 1.

(c) EVJOBEXECRESULTLOGSIZE

For this parameter, specify the size of event job execution result log files. This parameter takes effect if 1 or 2 is specified for the EVJOBEXECRESULTLOG environment setting parameter.

Format

"EVJOBEXECRESULTLOGSIZE"=dword:size-of-the-event-job-execution-result-log-file

Specifiable values

A hexadecimal value (in kilobytes) from 00000400 to 00004000 (1,024 to 16,384 in decimal)

Default value

dword:00004000 (16,384 in decimal)

Recommended value

Set the value appropriate for the operating environment.

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

If you want to change the path, size, or number of event job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

For details, see Cautionary note in (b) EVJOBEXECRESULTLOGPATH.

(d) EVJOBEXECRESULTLOGCOUNT

For this parameter, specify the number of event job execution result log files. This parameter takes effect if 1 or 2 is specified for the EVJOBEXECRESULTLOG environment setting parameter.

Format

"JOBEXECRESULTLOGCOUNT"=dword:number-of-the-event-job-execution-result-log-files

Specifiable values

A hexadecimal value from 00000001 to 00000040 (1 to 64 in decimal)

Default value

dword:00000004 (4 in decimal)

Recommended value

Set the value appropriate for the operating environment.

When the setting takes effect

The next time the JP1/AJS3 service starts

Cautionary note

If you want to change the path, size, or number of event job execution result log files, you must delete the log files and their management file before changing the value of the relevant environment setting parameter. If you do not delete these files, the new value is not applied.

For details, see Cautionary note in (b) EVJOBEXECRESULTLOGPATH.

4 Installation and Setup Considerations

This chapter discusses considerations related to JP1/AJS3 installation and setup.

When you have determined how to automate work tasks and configure the system, and have estimated the resources needed, the next step is to consider the installation and setup requirements.

4.1 Installation procedure

This section describes the things to remember when installing JP1/AJS3, and the decisions you will need to make beforehand.

4.1.1 Notes on installation

Note the following when installing JP1/AJS3.

(1) Upgrade installation from JP1/AJS2

When performing an upgrade installation from JP1/AJS2 to JP1/AJS3 version 8 or earlier, note the following:

The JP1/AJS2 Monitor service will be deleted and its functionality integrated with JP1/AJS3 services.

(2) Operating JP1/AJS3 using an AJS administrator account

You can set up an AJS administrator account before you install JP1/AJS3 so that you can operate JP1/AJS3 using the AJS administrator account. An AJS administrator can perform the same operations as users with superuser privileges, including starting and stopping JP1/AJS3 services, creating backups, and maintaining the database. By setting up an AJS administrator account, the system management work for JP1/AJS3 can be divided between the AJS administrator and a user with superuser privileges.

For details about AJS administrator accounts, see E. Operating JP1/AJS3 By Using an AJS Administrator Account (UNIX Only).

4.1.2 Pre-installation decisions

When installing JP1/AJS3, you must specify or select the items shown in the following table. Determine these settings in advance, according to your operating environment.

Table 4‒1: Pre-installation decisions

Item

Description

User information#3

Enter your user name and company name. These are mandatory.

Installation folders#3

Specify the folders in which to install the JP1/AJS3 programs.

Change the defaults as required.

The default installation folders of the products are:

JP1/AJS3 - Manager#1: system-drive\Program Files (x86)\HITACHI\JP1AJS2

JP1/AJS3 - Agent: system-drive\Program Files (x86)\HITACHI\JP1AJS2

JP1/AJS3 - View: system-drive\Program Files (x86)#2\HITACHI\JP1AJS2V

Setup

Specify this item only when you install JP1/AJS3 - Manager.

Specify whether to set up a database and scheduler service during installation. To set up the database, select the database model to be set up from the following three types:

small-scale model

medium-scale model

large-scale model

Select the database model according to how JP1/AJS3 is used. For details about how to estimate the database model, see 23.2 Estimating the database area in the JP1/Automatic Job Management System 3 Configuration Guide.

In the following cases, consider skipping the setup of databases and scheduler services during the installation and performing the setup after the installation is complete:

When you change the embedded database settings from the default

For details about the embedded database settings during installation, see 2.6.5 Database settings that are set up in JP1/AJS3.

When you use an external database as the JP1/AJS3 - Manager database

For details about the external database, see 2.11 Considering use of an external database in a cloud environment.

#1

JP1/AJS3 - Web Console will be installed in a different folder. The default installation folder is:

system-drive\Program Files\HITACHI\JP1AJS3WEB

#2

For 32-bit versions of Windows, replace Program Files (x86) with Program Files.

#3

You need to determine this item only when the OS is Windows.

For details about other points you must check, see 2.2.1 Points you must check before installation in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows) or 12.2.1 Points you must check before installation in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX).

4.2 JP1/AJS3 service settings

This section explains the types of JP1/AJS3 services and their default settings. Situations where you will need to change the settings are also described.

4.2.1 Types of JP1/AJS3 services

The following table describes JP1/AJS3 - Manager services.

Table 4‒2: JP1/AJS3 - Manager services

Service name

Description

JP1/AJS3 service

Manages job and jobnet definitions and the execution of jobs and jobnets. Scheduler services are included within the JP1/AJS3 service.

JP1/AJS3 Database service

Manages commands for running and operating on a database.

JP1/AJS3 Mail service

Controls monitoring of email transmissions when linked to a Windows mail system.

JP1/AJS3 Check Manager service

Issues instructions to the JP1/AJS3 Check Agent service to perform pre-execution checks of jobs defined in JP1/AJS3, and receives the check status back from the JP1/AJS3 Check Agent service.

JP1/AJS3 Check Agent service

Performs execution pre-checks of jobs defined in JP1/AJS3, on instruction from JP1/AJS3 Check Manager.

JP1/AJS3 Queueless Agent service

Accepts queueless job execution requests from JP1/AJS3 - Manager, and executes queueless jobs.

JP1/AJS3 Queueless File Transfer service

Accepts file transfer requests from the queueless job manager process, and sends data from transfer files or the standard error output file to the queueless job manager process.

JP1/AJS3 Autonomous Agent service

Executes flexible jobs.

JP1/AJS3 Autonomous Agent Messenger service

Communicates between the JP1/AJS3 Autonomous Agent services.

Note

If the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00, the JP1/AJS3 Database ClusterService service also starts. The JP1/AJS3 Database ClusterService service manages the operations of the database in a cluster environment.

The following table describes JP1/AJS3 - Web Console services.

Table 4‒3: JP1/AJS3 - Web Console services

Service name

Description

JP1/AJS3 Web Application Server service

Acts as a web application server and controls, executes, and manages web applications.

JP1/AJS3 HTTP Server service

Acts as a web server, and controls the display of HTML or images based on HTTP communications.

The following table describes JP1/AJS3 - Agent services.

Table 4‒4: JP1/AJS3 - Agent services

Service name

Description

JP1/AJS3 service

Executes work tasks.

JP1/AJS3 Mail service

Controls monitoring of email transmissions when linked to a Windows mail system.

JP1/AJS3 Queueless Agent service#

Accepts queueless job execution requests from JP1/AJS3 - Manager, and executes queueless jobs.

JP1/AJS3 Check Agent service

Performs pre-execution checks of jobs defined in JP1/AJS3, on instruction from JP1/AJS3 Check Manager.

JP1/AJS3 Autonomous Agent service#

Executes flexible jobs.

JP1/AJS3 Autonomous Agent Messenger service#

Communicates between JP1/AJS3 Autonomous Agent services.

#

JP1/AJS3 - Agent Minimal Edition does not provide this service.

Cautionary notes

For the service name of the JP1/AJS3 Database service, the setup identifier specified at installation is displayed. For the service name of the JP1/AJS3 Database ClusterService service that starts when the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00, the setup identifier specified at installation is also displayed. For details about the setup identifier, see the description of the -id option in ajsembdbsetup in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

In UNIX, a superuser must start the above services.

The JP1/Base service and JP1/AJS3 service need to be active to define or execute work tasks in JP1/AJS3. Start the JP1/Base service before starting the JP1/AJS3 service. Stop the JP1/Base and JP1/AJS3 services when you finish defining or executing work tasks.

In a manager/agent configuration, you need to start and end the JP1/AJS3 service on both JP1/AJS3 - Manager and JP1/AJS3 - Agent.

Do not change the system date and time after starting the JP1/AJS3 service as this will affect the jobnet execution schedule. For details about this issue, see 7.9.3 Changing the date and time of the system in the JP1/Automatic Job Management System 3 Administration Guide.

When you start JP1/AJS3 - View to perform operations on a jobnet registered for execution from JP1/AJS3 - View, make the time zone of the JP1/AJS3 - View host the same as the time zone of the connected JP1/AJS3 service.

When you perform operations on a jobnet from JP1/AJS3 - View, the time in the time zone in which the JP1/AJS3 service is running is displayed in JP1/AJS3 - View. Therefore, if the time zones are different, the time of actual operations and the time displayed in JP1/AJS3 - View will be out of sync by the difference between the two time zones. For details, see 2.4.1 Time zones.

When using the Windows mail system linkage functionality, you can choose whether to use the JP1/AJS3 Mail service or the desktop mail monitoring process. If you choose the mail monitoring process, the JP1/AJS3 Mail service is not started. For details, see 2.3.4 Setting up the environment for the mail system linkage in the JP1/Automatic Job Management System 3 Linkage Guide.

The JP1/AJS3 Database service is controlled by JP1/AJS3. During ordinary operations, you do not need to use the JP1/AJS3 Database service. When the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00, the JP1/AJS3 Database ClusterService service also starts. However, during ordinary operations, you do not need to use the JP1/AJS3 Database ClusterService service. Use the JP1/AJS3 Database ClusterService service only when you need to operate the embedded database manually.

4.2.2 Defaults for JP1/AJS3 services (Windows only)

This subsection explains the setup of the accounts used by the services.

The table below lists the defaults set in the JP1/AJS3 - Manager, JP1/AJS3 - Web Console, and JP1/AJS3 - Agent services.

Note that you cannot select the Allow Service to Interact with Desktop option.

Table 4‒5: Defaults for JP1/AJS3 - Manager, JP1/AJS3 - Web Console, and JP1/AJS3 - Agent services

Service name

Provided program

Startup Type

Account

JP1/AJS3

M, A

Manual

System

JP1/AJS3 Database identifier

M

Manual

System

JP1/AJS3 Mail

M, A

Manual

System

JP1/AJS3 Check Manager

M

Manual

System

JP1/AJS3 Check Agent

M, A

Manual

System

JP1/AJS3 Queueless Agent

M, A

Manual

System

JP1/AJS3 Queueless File Transfer

M

Manual

System

JP1/AJS3 Autonomous Agent

M, A

Automatic

System

JP1/AJS3 Autonomous Agent Messenger

M, A

Automatic

System

JP1/AJS3 Web Application Server

W

Automatic

System

JP1/AJS3 HTTP Server

W

Automatic

System

Legend:

M: JP1/AJS3 - Manager

W: JP1/AJS3 - Web Console

A: JP1/AJS3 - Agent

Note

The following points differ when the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00:

The startup type of JP1/AJS3 Database identifier is Automatic.

JP1/AJS3 Database ClusterService identifier also starts.

For JP1/AJS3 Database ClusterService identifier, the startup type is Manual and the account is System.

4.2.3 Changing the JP1/AJS3 service settings (Windows only)

This subsection describes the types of situations where it might be advisable to change the JP1/AJS3 service settings from the defaults. The JP1/AJS3 service setting for linking to another program is also explained.

(1) Changing the account for services provided by JP1/AJS3

Depending on the job execution environment, it might be better to change the account for the JP1/AJS3 services to a user account. Examine the user account settings in JP1/AJS3 services as needed.

The following describes the types of situations when you will need to change the account used by the following services:

JP1/AJS3 service

JP1/AJS3 Database service

JP1/AJS3 Check Manager service

JP1/AJS3 Check Agent service

JP1/AJS3 Queueless Agent service

JP1/AJS3 Queueless File Transfer service

JP1/AJS3 Autonomous Agent service

JP1/AJS3 Autonomous Agent Messenger service

JP1/AJS3 Web Application Server service

JP1/AJS3 HTTP Server service

When the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00, the account for the JP1/AJS3 Database ClusterService service also needs to be changed.

(a) When using network resources

If you use network resources (that is, shared jobs), change the account for the JP1/AJS3 services to a user account.

When a job batch file requires a connection to a network drive, making the account for the JP1/AJS3 services the same as the account for the user who starts the job will allow other jobs started from that user account to disconnect the network drive.

As the file name specified in the detailed definition of the job, instead of a path beginning with the network drive name, specify a path beginning with the computer name, as follows: \\computer-name\shared-folder\file-name

(b) When multiple scheduler services are activated and you want to avoid desktop heap shortages

Depending on the system environment, an error might occur when more than a certain number of scheduler services are activated concurrently. In this case, an error message (event ID 26) is output to the Windows event log, reporting that the application was not initialized correctly. This occurs when there are insufficient system resources (desktop heap shortage).

In JP1/AJS3, many control processes are activated by each scheduler service. When multiple scheduler services are activated concurrently, usage of the desktop heap increases proportionately and shortages might occur. In such cases, change the account used by the JP1/AJS3 services from the system account to a user account. This will prevent use of the same desktop heap area by both JP1/AJS3 services and other service programs.

(c) Privileges for running JP1/AJS3 services under a user account

The following describes the privileges you need to set when running the following services under a user account:

JP1/AJS3 service

JP1/AJS3 Database service

JP1/AJS3 Check Manager service

JP1/AJS3 Check Agent service

JP1/AJS3 Queueless Agent service

JP1/AJS3 Queueless File Transfer service

JP1/AJS3 Autonomous Agent service

JP1/AJS3 Autonomous Agent Messenger service

JP1/AJS3 Web Application Server service

JP1/AJS3 HTTP Server service

When the type of the embedded database is one used for JP1/AJS3 - Manager before version 10-00, privileges also need to be set for the JP1/AJS3 Database ClusterService service.

To run the above services under a user account, grant the following privileges to the user:

Administrators privilege

Allow log on locally

Log on as a service

Replace process level token

Increase process memory quota

Operation is not guaranteed if the set user account does not have these privileges.

Set these privileges in the Local Security Policy.

When the account under which JP1/AJS3 services are activated is changed from the system account to a user account, the size of the available desktop heap also changes. This might affect the number of jobs (batch files and script files) that can be executed concurrently.

Cautionary notes

Set the same user account for the JP1/AJS3 services on all logical hosts and physical hosts.

After setting the required privileges for the account used to activate JP1/AJS3 services, you must restart the services for the privileges to take effect.

In a domain environment that uses Active Directory, the setup procedure differs for the host that is the domain controller and for the hosts in the domain. For details, see the explanation in the JP1/Base User's Guide about how to grant user rights to an OS user in an Active Directory environment.

(d) Procedure for changing the JP1/AJS3 service startup account to a user account

The default of the JP1/AJS3 service startup account is the system account. Use the following procedure for changing the JP1/AJS3 service startup account to a user account.

Stop the JP1/AJS3 service.

Change the account used by the JP1/AJS3 services from the system account to a user account.

Grant the following privileges to OS user accounts:

Administrators privilege

Allow log on locally

Log on as a service

Replace a process level token

Increase process memory quota

Restart the JP1/AJS3 service.

(2) Account for linking to the mail service

The mail service account does not have to be the same as the JP1/AJS3 services account.

When mail system linkage is running in the JP1/AJS3 Mail service, set the account of a user for whom a mail profile has been defined in the JP1/AJS3 Mail service. Also, set the following privileges:

Allow log on locally

Log on as a service

Operation is not guaranteed if the set user account does not have these privileges.

Set these privileges in the Local Security Policy.

(3) Required changes for linking to JP1/Power Monitor

To perform power control linked with JP1/Power Monitor, you must start JP1/AJS3 using the JP1/Base startup control. In this case, set the Startup Type of the JP1/AJS3 service to Manual.

(4) Required changes for using the JP1/Base startup control

By default, the JP1/AJS3 service starts under the JP1/Base startup control.

When using the JP1/Base startup control:

Set the Startup Type of the JP1/AJS3 service to Manual.

If you have upgraded from JP1/Base version 8 to version 9 or later, comment-out the automatic startup parameter Jp1AJS2MONITOR in the JP1/Base start sequence definition file Jp1svprm.dat.

When not using the JP1/Base startup control:

The Startup Type of the JP1/AJS3 service can be set as Manual or Automatic.

4.2.4 Settings for starting and stopping JP1/AJS3 services automatically

The JP1/AJS3 services can be activated and terminated automatically at system startup and shutdown.

Do not enable automatic startup if you want the OS to start up quickly or when the operator needs to start JP1/AJS3 manually.

In Windows:

Because the JP1/Base startup control is enabled, by default, the JP1/AJS3 services will start automatically. If you do not want to use the JP1/Base startup control, disable it as explained in the section about setting the services start/stop sequence in the JP1/Base User's Guide.

Note that the start sequence definition file (JP1SVPRM.DAT), used to set the start and stop sequence for services, contains the following sections in which you can specify the settings for the JP1/AJS3 service and JP1/AJS3 Mail service. Although the default name is JP1/AJS2, the settings below take effect as JP1/AJS3 settings.

JP1/AJS3 service settings:

[Jp1AJS2]
Name=JP1/AJS2
ServiceName=JP1_AJS2
StopCommand=jajs_spmd_stop.exe

JP1/AJS3 Mail service settings:

[Jp1AJS2MAIL]
Name=JP1/AJS2 Mail
ServiceName=JP1_AJS2_Mail

In UNIX:

For details about the settings for automatically starting and stopping JP1/AJS3 services, see 15.9.1 Setting automatic startup and termination of the JP1/AJS3 service in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary notes

Windows shutdown does not wait for JP1/AJS3 termination to complete. Shutting down Windows while JP1/AJS3 is active might corrupt the JP1/AJS3 data files or cause other problems. To shut down Windows manually, execute the JP1/Power Monitor power control command (aompwcon). If JP1/Power Monitor is not installed, first stop the JP1/AJS3 services, and then shut down the system.

Do not register and execute the OS shutdown command in a PC job or flexible job. If you wish to shut down the OS using automatic job execution, consider installing JP1/Power Monitor and executing a Local Power Control job as an action job.

4.2.5 Starting multiple instances of the JP1/AJS3 services

The JP1/AJS3 services of JP1/AJS3 - Manager and JP1/AJS3 - Agent can be started as multiple instances in a single host, enabling operation in a cluster environment. To start multiple instances of the JP1/AJS3 services, define logical hosts that will allow the physical host to be used as multiple virtual hosts, and then set up the environment for services to start on a logical host basis.

To start multiple JP1/AJS3 services on a logical host basis, set up the environment for each logical host. Prepare sufficient system resources (semaphores, virtual memory, shared memory, disk space, and so on) for the number of instances of the JP1/AJS3 services that will be activated simultaneously.

The following figure shows the system operation with multiple instances of the JP1/AJS3 service.

Figure 4‒1: Activating multiple instances of JP1/AJS3 services

4.3 Setup of JP1/AJS3 - Manager

This section describes the settings involved in setting up a JP1/AJS3 - Manager host. Before you begin this task, decide whether to use the defaults or customized settings for JP1/AJS3 - Manager.

For details about performing these settings, see the JP1/Automatic Job Management System 3 Configuration Guide.

4.3.1 Environment settings for event jobs

This subsection explains the environment settings (environment setting parameters) related to event jobs on a JP1/AJS3 - Manager host, and considers items that can be specified as options when event jobs are used. Consider the setting according to the operation environment.

(1) Linking with a mail system

By using the mail system linkage function, you can define mail transmission and reception into a jobnet.

For details about the environment settings (environment setting parameters) when linking with a mail system, see the section corresponding to the OS. For Windows, see 2.3.4(4) Environment setting parameters used by the mail system linkage function in the JP1/Automatic Job Management System 3 Linkage Guide. For UNIX, see 2.4.2(3) Environment setting parameters used for email reception monitoring jobs in the JP1/Automatic Job Management System 3 Linkage Guide.

For details about setting procedures, if necessary, see the section corresponding to the OS. For Windows, see 2.3.4 Setting up the environment for the mail system linkage in the JP1/Automatic Job Management System 3 Linkage Guide. For UNIX, see 2.4.2 Setting up the environment for an email reception monitoring job in the JP1/Automatic Job Management System 3 Linkage Guide.

(2) Setting the log size for event jobs

The size of the log file for event jobs depends on such things as the number of event jobs executed and the number of monitoring conditions satisfied. Therefore, as a guideline, specify a log size so that log data can be kept for 1 to 3 days, or at least for 24 hours. To estimate the required log size, see 3.4.3 Estimating the size of the log information output by event jobs.

(3) Processing events in order of occurrence

When an event job has start conditions, events that trigger the job might occur in succession but be processed in a different order, depending on the communication conditions. You might want to preserve the actual order of events that satisfied the start conditions if, for example, the event information will be passed to a parameter. In this case, use the event order option.

Set this option on all agent hosts that execute event jobs. For details, see 6.3.2 Setting the event order option in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.3.2 Setting the event order option in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(4) Passing the status of a Monitoring Files job

You can save information as needed while a Monitoring Files job is monitoring the target files. This allows the job status to be passed at restart if the JP1/AJS3 service temporarily stops. For example, in a cluster system, if the JP1/AJS3 service is stopped and restarted while a Monitoring Files job is running, the job can be resumed from its previous monitoring status. We recommend that you use this setting to maintain the consistency of a Monitoring Files job should the JP1/AJS3 service stop.

To pass the monitoring status, the Monitoring Files job needs to be continuously active. Whether the monitoring status can be passed depends on whether the Monitoring Files job continues running or is stopped.

For the conditions under which the monitoring status is passed, see the description of the status passing option for Monitoring Files jobs in 7.6.2 Notes on the Monitoring Files job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

For the setting procedure, see 6.3.3 Setting the status passing option for the file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.3.3 Setting the status passing option for the file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(5) Passing event data containing double quotation marks

The information received by an event job can be passed to the parameters of standard jobs and action jobs. Any double quotation marks (") contained in the event data to be passed must be preceded by a backslash (\) when the event is issued. If the backslash is missing, the double quotation mark will be ignored or other issues might occur when the received event data is passed.

To prevent this, we recommend that you set an option to pass data containing double quotation marks exactly as in the issued event.

When you set this option, JP1/AJS3 inserts a backslash before each double quotation mark. This allows the information received by an event job to be passed to a job parameter regardless of whether it contains any double quotation marks.

If a backslash already precedes a double quotation mark in the information to be passed, this option adds a second backslash. Therefore, the string AB\"C, for example, will be passed as AB\"C, not AB"C. If you have already added backslashes intentionally, do not set this option.

Cautionary note

The received event data, passed from an event job to a parameter in a standard job or action job, must fit within the maximum length of that parameter. Note that with this option specified, there will be an extra backslash before any double quotation mark.

Consider the effects of passing data containing double quotation marks when this option is enabled, with reference to the following example:

Example:

The maximum length of a command statement in a Unix job is 1,023 bytes. If there are 1,023 bytes of event data containing a double quotation mark, specifying this option will result in an error because the passed data will exceed 1,024 bytes when the backslash is inserted.

For details about setting this option, see 6.3.4 Passing event data containing double quotation marks in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.3.4 Passing event data containing double quotation marks in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

4.3.2 Activating multiple scheduler services concurrently

A scheduler service is a control unit for managing root job groups, and is configured within the JP1/AJS3 services on a manager host. One or more root job groups must be defined at the highest level of the scheduler service hierarchy. The name of a root job group is a forward slash (/).

The following figure shows a configuration with multiple scheduler services activated.

Figure 4‒2: Using multiple scheduler services

When you use multiple scheduler services, the root job groups can be managed in different scheduler services. However, regardless of how many scheduler services are used, resources might be stretched in a system where more than 4,000 jobnets and jobs need to be managed (defined, registered for execution, and monitored) in one scheduler service. If your system has several CPUs, consider running multiple scheduler services concurrently.

For example, you could activate multiple scheduler services and divide work tasks among them. This would enable CPU resources to be utilized efficiently by each scheduler service, and each scheduler service would be able to execute its own work tasks (jobnets and jobs) independently of the others. Test runs could also be performed without affecting other operations.

You must also consider running multiple scheduler services when a very large number of jobnets need to be registered for execution. Taking account of processing performance, divide the jobnets into about 4,000 per scheduler service. Splitting up jobnets per work task can also help to reduce jobnet size.

A maximum of 20 scheduler services can be activated concurrently on one computer, including both the physical host and the logical hosts. However, depending on the system environment, if you specify more than a certain number of concurrent scheduler services in the environment settings, some services might not start.

To activate multiple scheduler services concurrently, define each one separately in the environment settings for each logical host. For the required settings, see 6.1.1 Settings for starting multiple scheduler services in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.1.1 Settings for starting multiple scheduler services in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

To start or stop scheduler services individually, execute the jajs_spmd or jajs_spmd_stop command with the -n jajs_schd option specified. You can execute these commands while JP1/AJS3 services are active. For details, see 7.5 Starting and stopping only the scheduler service in the JP1/Automatic Job Management System 3 Administration Guide.

(1) Activating multiple scheduler services on a Windows host

Depending on the system environment, an error might occur when more than a certain number of schedulers are activated concurrently. In this case, an error message reports that the application was not initialized correctly.

This error occurs when there are insufficient system resources (desktop heap shortage).

In JP1/AJS3, each scheduler service activates many control processes. When multiple scheduler services are activated concurrently, usage of the desktop heap increases proportionately and shortages might occur. In such cases, take the following measures.

(a) Use the desktop heap area specific to JP1/AJS3

To use the desktop heap area specific to JP1/AJS3, change the JP1/AJS3 services account to a user account. The system account is set by default for JP1/AJS3 services.

For details about this setting, see 4.2.3(1) Changing the account for services provided by JP1/AJS3.

(b) Adjust the desktop heap size by editing the registry

Edit the Windows registry to adjust the desktop heap size. For details about the procedure, see the relevant articles on Microsoft's Help and Support website. Usage of the desktop heap depends on your system environment. Be sure to consider the consequences before changing the heap size.

(2) Activating multiple scheduler services on a UNIX host

Increasing the number of scheduler services will increase system resource usage in direct proportion. If sufficient system resources cannot be allocated for the number of scheduler services you are using, an error might occur. Set the number of scheduler services to be activated concurrently once you have estimated the memory requirements, disk space requirements, kernel parameters, and other system resources needed, as described in 3. Estimates.

4.3.3 Options related to job execution

This subsection describes the environment setting items (environment setting parameters) of the job execution environment which you can specify as options for job execution. Set these options according to your operating environment.

For those environment setting parameters of the job execution environment which are not described herein, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

For the setting procedure, see 4.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 14.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(1) Defining the work path for job execution as a variable

If a different installation path is used for JP1/AJS3 at each agent host, or if the JP1/AJS3 installation path at an agent host is not defined in the environment variable PATH, by defining the installation path at the agent hosts as a variable, you can enable jobs to be executed regardless of where JP1/AJS3 is installed on the agent.

We recommend that you define the work path for job execution as a variable when JP1/AJS3 runs in different environments; for example, when the executable files for job execution reside on the C drive in one agent host, and on the D drive in another agent host.

For details about setting the work path as a variable, see 6.2.1 Defining variables for work paths used during job execution in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.2.1 Defining variables for work paths used during job execution in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(2) Executing jobs with long file names (Windows only)

When a job is executed, the name of the executable file is converted to a short file name recognized by NTFS (NT file system) volumes and FAT (file allocation table) volumes. We recommend that you enable this option if you want to run job executable files with long file names without converting them to short file names.

For details about this option, see 6.2.15 Executing a job by using a long file name in the JP1/Automatic Job Management System 3 Configuration Guide.

(3) Defining the search path for transfer files

In JP1/AJS3, you can transfer the text files required for job execution from the manager host to an execution agent host. For example, you can transfer a settings file (.ini file) in which the environment (path and so on) of the executable file is defined.

You can pre-define a search path. When you specify the files to transfer from the manager host to the agent host, JP1/AJS3 will look for the files in that search path, and forward those found.

We recommend that you enable this option if you want to define the files to be transferred without specifying their paths.

For details about this option, see 6.2.2 Defining search paths for a file to be transferred in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.2.2 Defining search paths for a file to be transferred in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(4) Setting the pipe communication timeout value for an agent (UNIX only)

A timeout might occur during pipe communication between agent processes of the job execution control. Possible causes of this timeout are:

A large number of jobs were executed at one time.

The CPU has a high load.

Due to insufficient real memory, the agent process of the job execution control was swapped out and not executed for 300 seconds or longer.

If these problems remain unresolved and pipe communication timeout errors are likely to recur, we recommend that you increase the timeout for pipe communication at the host on which the agent processes run.

Important

If the setting for pipe communication timeout is too long, job errors might take longer to be detected.

For details about setting the pipe communication timeout, see 15.2.15 Changing the timeout value for pipe communication of the agent in the JP1/Automatic Job Management System 3 Configuration Guide.

(5) Placing restrictions on file reception

If JP1/AJS3 version 11-00 or later is installed in a new installation, a maximum file size of 5 megabytes is placed on the job# execution result files (the standard output and standard error output files) and transferred files.

#

The targeted jobs include PC jobs, Unix jobs, custom jobs, QUEUE jobs executed on JP1/AJS3, and submit jobs. The event jobs, passing information settings jobs, HTTP connection jobs, flexible jobs, and queueless jobs are excluded.

If the file size of a result file exceeds the maximum value, the data exceeding the maximum value is discarded. If the file size of a transfer file exceeds the maximum value, the data exceeding the maximum value is not received. Note that if you execute a passing information settings job by using a standard output file that exceeds the maximum value, the information might not be passed properly.

In such a case, modify the value set for the file reception restriction. For details about the settings, see the section corresponding to the OS. For Windows, see 6.2.7 Placing restrictions on file reception in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 15.2.7 Placing restrictions on file reception in the JP1/Automatic Job Management System 3 Configuration Guide.

(6) Placing restrictions on file transmission

If JP1/AJS3 version 11-00 or later is installed in a new installation, a maximum file size of 3 megabytes is placed on the job# execution result files (the standard output and standard error output files).

#

The targeted jobs include PC jobs, Unix jobs, custom jobs, QUEUE jobs executed on JP1/AJS3, and submit jobs. The event jobs, passing information settings jobs, HTTP connection jobs, flexible jobs, and queueless jobs are excluded.

In the case of result files, data beyond the maximum value is discarded and not transmitted. Note that if you execute a passing information settings job by using a standard output file that exceeds the maximum value, the information might not be passed properly.

In such a case, modify the value set for the file transmission restriction. For details about the settings, see the section corresponding to the OS. For Windows, see 6.2.27 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 15.2.24 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide.

4.3.4 Environment settings for action jobs

This subsection discusses the options you can set for action jobs. Determine which options to set according to your operating environment.

(1) Sending emails using the email sending job

When you use the email sending job in Windows, you can choose either of the following:

Email sending job without Outlook

Email sending job with Outlook

The following table describes the advantages and disadvantages of each.

Table 4‒6: Advantages and disadvantages of the email sending job with and without Outlook

Email sending job

Advantages

Disadvantages

Without Outlook

You can send emails without preparing Outlook.

You cannot check the results of sending emails in the email software. (Instead, check the execution result for the email sending jobs.)

You cannot specify the time for email transmission.

You cannot receive read receipts for messages.

With Outlook

You can check the results of sending emails in Outlook.

You can specify the delivery time by using the appropriate Outlook option.

You can obtain read receipts by using the appropriate Outlook option.

You need to prepare Outlook.

On the same host, you can choose either to use Outlook or not to use Outlook. You cannot choose both options. Select the option that is appropriate for operation of your system.

You can use email reception monitoring jobs even when you send emails without using Outlook. However, note that if you use email reception monitoring jobs, Outlook must still be installed.

Cautionary note

When you use the email sending job without Outlook to send emails, version 10-00 or later of JP1/AJS3 - Manager or JP1/AJS3 - Agent must be installed on the relevant agent.

For details about mail system linkage, see 2. Linking Mail Systems in the JP1/Automatic Job Management System 3 Linkage Guide.

The following table describes the differences when Outlook is not used and when it is used.

Table 4‒7: Differences when Outlook is not used and used

No.

Item

Outlook not used

Outlook used

1

Mail system

SMTP#1

Exchange Server or SMTP and POP3

2

Logical host that sends emails

Multiple logical hosts can send emails.

Only one logical host can send emails.

3

Specification of display names or aliases as recipients

Not possible.

Same as Outlook and mail system

4

Automatic linefeed for messages

Not possible.

Same as the text wrapping option in Outlook if the WrapTextWithOutlookOption environment setting parameter is set to Y.#2

5

Time the email was delivered to the recipient

Not possible.

Same as the delivery time option in Outlook

6

Read receipts for messages (Setting for sending a read receipt when a sent email is read by the recipient)

Not possible.

Same as the read receipt option in Outlook

7

Retransmission of emails

Re-execute the email sending job.

Use Outlook to re-send emails.

8

Confirmation of sent emails

Check the execution result for the email sending jobs.

Check Outbox and Sent Items in Outlook.

9

Transmission of emails without subjects

Emails are sent with one space as the subject.

Same as Outlook

10

Attachments exceeding 10 megabytes

Depends on the upper limit of the mail server. However, 10 megabytes is recommended as the upper limit.

Same as Outlook

11

Maximum size of the string for the destination address

A string of 256 bytes or shorter can be specified.

A string of 256 bytes or shorter and of 255 characters or shorter can be specified.

If an address with 256 or more characters is specified, the first 255 characters will be regarded as the address.

12

Maximum size of the string for the subject

A string of 256 bytes or shorter can be specified.

A string of 256 bytes or shorter and of 255 characters or shorter can be specified.

If a subject with 256 or more characters is specified, the first 255 characters will be regarded as the subject.

#1

As the authentication method, POP before SMTP, SMTP-AUTH PLAIN, or SMTP-AUTH LOGIN can be specified. When POP before SMTP is used as the authentication method, POP3 is also required.

#2

For details about WrapTextWithOutlookOption environment setting parameter, see 2. Linking Mail Systems in the JP1/Automatic Job Management System 3 Linkage Guide.

4.3.5 Environment settings related to the backup and recovery of embedded databases

Multiple methods for the backup and recovery of an embedded database are available. Each method has different advantages. Some methods require setup before use. See 5.2.1(5) Backing up and restoring an embedded database and consider the setup required to use each backup and recovery method.

4.4 Setup of JP1/AJS3 - Agent

This section describes the settings involved in setting up a JP1/AJS3 - Agent host. Before you begin this task, decide whether to use the defaults or customized settings for JP1/AJS3 - Agent.

For details about performing these settings, see the JP1/Automatic Job Management System 3 Configuration Guide.

4.4.1 Environment settings for event jobs

This subsection explains the environment settings (environment setting parameters) related to event jobs on a JP1/AJS3 - Agent host, and considers items that can be specified as options when event jobs are used. Consider the setting according to the operation environment.

(1) Linking with the mail system

You can use the mail system linkage function to define mail transmission and reception to a jobnet.

For details about the environment settings (environment setting parameters) when linking with a mail system, see the section corresponding to the OS. For Windows, see 2.3.4(4) Environment setting parameters used by the mail system linkage function in the JP1/Automatic Job Management System 3 Linkage Guide. For UNIX, see 2.4.2(3) Environment setting parameters used for email reception monitoring jobs in the JP1/Automatic Job Management System 3 Linkage Guide.

For details about setting procedures, if necessary, see the section corresponding to the OS. For Windows, see 2.3.4 Setting up the environment for the mail system linkage in the JP1/Automatic Job Management System 3 Linkage Guide. For UNIX, see 2.4.2 Setting up the environment for an email reception monitoring job in the JP1/Automatic Job Management System 3 Linkage Guide.

(2) Setting the log size for event jobs

The size of the log file for event jobs depends on such things as the number of event jobs executed and the number of monitoring conditions satisfied. As a general guide, set a log size large enough for 24 hours' worth of entries as a minimum, or 1-3 days' worth preferably. To estimate the required log size, see 3.4.3 Estimating the size of the log information output by event jobs.

(3) Processing events in order of occurrence

When an event job has start conditions, events that trigger the job might occur in succession but be processed in a different order, depending on the communication conditions. You might want to preserve the actual order of events that satisfied the start conditions if, for example, the event information will be passed to a parameter. In this case, use the event order option. Set this option on all agent hosts that execute event jobs. For details, see 6.3.2 Setting the event order option in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.3.2 Setting the event order option in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(4) Passing the status of a Monitoring Files job

You can save information as needed while a Monitoring Files job is monitoring the target files. This allows the job status to be passed at restart if the JP1/AJS3 service temporarily stops. For example, in a cluster system, if the JP1/AJS3 service is stopped and restarted while a Monitoring Files job is running, the job can be resumed from its previous monitoring status. We recommend that you use this setting to maintain the consistency of a Monitoring Files job should the JP1/AJS3 service stop.

To pass the monitoring status, the Monitoring Files job needs to be continuously active. Whether the monitoring status can be passed depends on whether the Monitoring Files job continues running or is stopped.

For the conditions under which the monitoring status is passed, see the description of the status passing option for Monitoring Files jobs in 7.6.2 Notes on the Monitoring Files job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

For the setting procedure, see 6.3.3 Setting the status passing option for the file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.3.3 Setting the status passing option for the file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

4.4.2 Options related to job execution

This subsection describes the environment setting items (environment setting parameters) of the job execution environment which you can specify as options for job execution. Set these options according to your operating environment.

For those environment setting parameters of the job execution environment which are not described herein, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

For the setting procedure, see 4.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 14.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(1) Defining the work path for job execution as a variable

If a different installation path is defined for JP1/AJS3 at each agent host, or if the JP1/AJS3 installation path at an agent host is not defined in the environment variable PATH, by defining the installation path at the agent hosts as a variable, you can enable jobs to be executed regardless of where JP1/AJS3 is installed on the agent.

We recommend that you define the work path for job execution as a variable when JP1/AJS3 runs in different environments; for example, when the executable files for job execution reside on the C drive in one agent host, and on the D drive in another agent host.

For details about setting the work path as a variable, see 6.2.1 Defining variables for work paths used during job execution in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.2.1 Defining variables for work paths used during job execution in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(2) Executing jobs with long file names (Windows only)

When a job is executed, the name of the executable file is converted to a short file name recognized by NTFS (NT file system) and FAT (file allocation table) volumes. We recommend that you enable this option if you want to run job executable files with long file names without converting them to short file names.

For details about this option, see 6.2.15 Executing a job by using a long file name in the JP1/Automatic Job Management System 3 Configuration Guide.

(3) Setting the pipe communication timeout value for an agent (UNIX only)

A timeout might occur during the pipe communication between agent processes of the job execution control. Possible causes of this timeout are:

A large number of jobs were executed at one time.

The CPU has a high load.

The agent process of the job execution control was swapped out for 300 seconds or longer due to insufficient real memory, and the job was not executed.

If these problems remain unresolved and pipe communication timeout errors are likely to recur, we recommend that you increase the timeout for pipe communication at the host on which the agent processes run.

Important

If the setting for pipe communication timeout is too long, job errors might take longer to detect.

For details about setting the pipe communication timeout, see 15.2.15 Changing the timeout value for pipe communication of the agent in the JP1/Automatic Job Management System 3 Configuration Guide.

(4) Placing restrictions on file transmission

When JP1/AJS3 version 11-00 or above is installed as a new installation, the maximum file size of 3 megabytes is placed on the job# execution result files (standard output and standard error output files).

#

The targeted jobs include PC jobs, Unix jobs, custom jobs, QUEUE job executed on JP1/AJS3, and submit jobs. The event jobs, passing information settings jobs, HTTP connection jobs, flexible jobs, and queueless jobs are excluded.

In the case of result files, data beyond the maximum value is discarded and not transmitted. Note that if you execute a passing information settings job by using a standard output file exceeding the maximum value, the information might not be passed properly.

In such a case, modify the value set for the file transmission restriction. For details about the settings, see the section corresponding to the OS. For Windows, see 6.2.27 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 15.2.24 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide.

4.4.3 Environment settings for action jobs

This subsection discusses the options you can set for action jobs. Determine which options to set according to your operating environment.

(1) Sending emails using the email sending job

When you use the email sending job in Windows, you can choose either of the following:

Email sending job without Outlook

Email sending job with Outlook

The following table describes the advantages and disadvantages of each.

Table 4‒8: Advantages and disadvantages of the email sending job with and without Outlook

Email sending job

Advantages

Disadvantages

Without Outlook

You can send emails without preparing Outlook.

You cannot check the results of sending emails in the email software. (Instead, check the execution result for the email sending jobs.)

You cannot specify the time for email transmission.

You cannot receive read receipts for messages.

With Outlook

You can check the results of sending emails in Outlook.

You can specify the delivery time by using the appropriate Outlook option.

You can obtain read receipts by using the appropriate Outlook option.

You need to prepare Outlook.

On the same host, you can choose either to use Outlook or not to use Outlook. You cannot choose both options. Select the option that is appropriate for operation of your system.

Cautionary note

When you use the email sending job without Outlook to send emails, version 10-00 or later of JP1/AJS3 - Manager or JP1/AJS3 - Agent must be installed on the relevant agent.

For details about mail system linkage, see 2. Linking Mail Systems in the JP1/Automatic Job Management System 3 Linkage Guide.

The following table describes the differences when Outlook is not used and when it is used.

Table 4‒9: Differences when Outlook is not used and used

No.

Item

Outlook not used

Outlook used

1

Mail system

SMTP#1

Exchange Server or SMTP and POP3

2

Logical host that sends emails

Multiple logical hosts can send emails.

Only one logical host can send emails.

3

Specification of display names or aliases as recipients

Not possible.

Same as Outlook and mail system

4

Automatic linefeed for messages

Not possible.

Same as the text wrapping option in Outlook if the WrapTextWithOutlookOption environment setting parameter is set to Y.#2

5

Time the email was delivered to the recipient

Not possible.

Same as the delivery time option in Outlook

6

Read receipts for messages (Setting for sending a read receipt when a sent email is read by the recipient)

Not possible.

Same as the read receipt option in Outlook

7

Retransmission of emails

Re-execute the email sending job.

Use Outlook to re-send emails.

8

Confirmation of sent emails

Check the execution result for the email sending jobs.

Check Outbox and Sent Items in Outlook.

9

Transmission of emails without subjects

Emails are sent with one space as the subject.

Same as Outlook

10

Attachments exceeding 10 megabytes

Depends on the upper limit of the mail server. However, 10 megabytes is recommended as the upper limit.

Same as Outlook

11

Maximum size of the string for the destination address

A string of 256 bytes or shorter can be specified.

A string of 256 bytes or shorter and of 255 characters or shorter can be specified.

If an address with 256 or more characters is specified, the first 255 characters will be regarded as the address.

12

Maximum size of the string for the subject

A string of 256 bytes or shorter can be specified.

A string of 256 bytes or shorter and of 255 characters or shorter can be specified.

If a subject with 256 or more characters is specified, the first 255 characters will be regarded as the subject.

#1

As the authentication method, POP before SMTP, SMTP-AUTH PLAIN, or SMTP-AUTH LOGIN can be specified. When POP before SMTP is used as the authentication method, POP3 is also required.

#2

For details about WrapTextWithOutlookOption environment setting parameter, see 2. Linking Mail Systems in the JP1/Automatic Job Management System 3 Linkage Guide.

4.5 Environment settings for JP1/AJS3 - View

This section describes what to consider when setting the environment for JP1/AJS3 - View. Determine the following so that JP1/AJS3 - View can be used in an appropriate manner for your system right from the start:

Settings in the Preferences dialog box

Use of common settings (common user profile)

Use of the system common settings file

Window display statuses and refresh interval

Columns to display

Defaults for radio buttons and check boxes

Whether information about the connection-destination manager host is to be displayed in a window

You can set the JP1/AJS3 - View environment on each host running the program, and for each JP1 user who will log in to JP1/AJS3 - View, according to how the program will be used. Alternatively, you can use a common user profile, which allows all JP1 users to use JP1/AJS3 - View with the same settings. For details about setting user profiles, see 4.5.2 Common settings for JP1 users.

For details about JP1/AJS3 - View settings other than in the Preferences dialog box, see 11.1.1 Types of customization methods in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.1 Settings in the Preferences dialog box

This subsection describes the items you can set in the Preferences dialog box of JP1/AJS3 - View. Decide your preferences for the following items beforehand, so that JP1/AJS3 - View can be used in line with your system operation right from the start.

Table 4‒10: Items to set in the Preferences dialog box

Page

Item

Login

Auto login

Start mode

View customize setting

Main

Icon color

Show color image in status and result

Display status of a job group

Double-click on jobnet

Exclusive edit when Jobnet Editor starts

Monitoring mode when Jobnet Monitor starts

Editor / Monitor

Unit name new line

Display comments

Highlighted display

Double-click in unit

Schedule

First execution time

Daily display time

Simulation

Order display by:

Root jobnet with no schedule

Planning group

General

Change icon color

Priority of delay display color

Hold plan

Other

Trace level

Max. log file size

Setting file

(1) Login page

Decide the following:

Whether to log in to JP1/AJS3 - Manager automatically when JP1/AJS3 - View starts

What display format to use in JP1/AJS3 - View

Whether the View customization settings file (jajsCustomizeView) is to be loaded when JP1/AJS3 - View starts

Auto login

Decide whether to log in to JP1/AJS3 - Manager automatically when JP1/AJS3 - View starts. Set this option if you want to skip the login procedure in the Login screen. However, without the login procedure, anyone will be able to log in to JP1/AJS3 - Manager. If there are security issues, do not perform this setting. Note also that the values you specify on the Login page are saved to an insecure JP1/AJS3 local file. Use auto login only in an environment protected by the OS security feature.

Auto login is disabled when you log in to JP1/AJS3 - View from JP1/IM - View. Log in to JP1/AJS3 - View using the JP1 user name and password that you used for logging in to JP1/IM - View. This JP1 user name and password are set in the displayed Login screen.

Start mode

Decide what display format to use in JP1/AJS3 - View. The display format in the JP1/AJS3 - View window is referred to as the Start mode. You can select any of these three options:

Normal

Displays only the target units and the available menu commands according to the purpose of the operation (definition, execution, or monitoring).

This option is best for preventing mistakes, and when the JP1 users logging in to the system each perform different types of operations.

Monitoring

Displays a window customized for monitoring units. You can specify target units and monitor those units only.

Compatible

Enables the same operability as in JP1/AJS2 - View version 8 and earlier. The windows will be displayed in this mode if you have performed an upgrade installation to JP1/AJS3 - View version 9.

This mode is suitable for users who are familiar with operations in JP1/AJS2 - View version 8 or earlier, where the menu commands are not explicitly grouped by purpose (definition, execution, or monitoring).

View customize setting

Consider whether the View customization settings file (jajsCustomizeView) is to be loaded when JP1/AJS3 - View starts. Information about the connection-destination manager host can be displayed in a window by loading the View customization settings file (jajsCustomizeView). The user can specify the information items to be displayed. If there are multiple manager hosts that the user can connect to from JP1/AJS3 - View, the information about the target manager host displayed in a window will help the user connect to the correct manager host.

The following figure shows an example of information about connection-destination manager hosts displayed in a window.

Figure 4‒3: Example of information about connection-destination manager hosts displayed in a window

(2) Main page

Decide the following:

How to display units in the list area of the JP1/AJS3 - View window

Whether to open the Jobnet Editor window or Jobnet Monitor window from the JP1/AJS3 - View window, and what to display in the Jobnet Monitor window

Icon color

You can select whether the color of icons displayed in the Name column of the list area should be based on the unit status or the operation result.

Select Use status color to show the status of the active generation.

For example, with Use status color selected, the jobnet icon will appear gray for a jobnet that ends abnormally and does not have a subsequent execution schedule (not scheduled for execution state). With Use result color selected, the jobnet icon will be light red.

Show color image in status and result

You can display different colors in the Status and Result columns, based on the status indicated in the text display. This option is useful for visually checking statuses and execution results in the JP1/AJS3 - View window.

Display status of a job group

The status of a job group can be represented by the background color of the job group icon in the list area. The status color represents the status of the jobnets in the job group. The Status and Result columns show the status and execution results of the job group.

When a job group has multiple jobnets, any of which has ended abnormally, the job group is shown in the abnormal end color. When a jobnet in a nested job group ends abnormally, the abnormal end color is applied to the upper-level job groups, and to the top-level job group. Thus, this option is useful for visually checking the status of jobnets in a job group in the JP1/AJS3 - View window. You can keep track of the status of each job group without having to open them by double-clicking the job group icons. Do not use this option if you have a considerable number of units, as the display performance declines when a job group contains many jobnets and jobs.

For details about the rules governing whether the status of a lower-level jobnet affects the upper-level job groups, see 12.3.42 Preferences dialog box in the JP1/Automatic Job Management System 3 Operator's Guide.

Double-click on jobnet

You can select any of the following as the window to display when you double-click a jobnet in the list area:

Open jobnet monitor and show status

Open jobnet monitor and show result

Open jobnet editor

On a host where JP1/AJS3 - View is used as a terminal for defining jobnets and jobs in a work flow, we recommend setting the Jobnet Editor window (for defining jobnet definition information) as the window to be displayed when a jobnet is selected.

On a host where JP1/AJS3 - View is used as a terminal for monitoring work tasks, not for editing jobnet definitions, we recommend setting the Jobnet Monitor window (for viewing jobnet statuses and results) as the window to be displayed.

Exclusive edit when Jobnet Editor starts

To edit a jobnet in the Jobnet Editor window, the jobnet definition information needs to be locked so that it cannot be updated by anyone else. For JP1 users who will be editing jobnet definitions, we recommend setting this option to place a lock on the displayed information when the Jobnet Editor window opens.

Monitoring mode when Jobnet Monitor starts

You can select the type of information displayed when the user opens the Jobnet Monitor window from the JP1/AJS3 - View window. Select either of the following:

Monitor the previous status

The Jobnet Monitor window shows only the generation displayed in the JP1/AJS3 - View window's list area. If the status of the jobnet changes after the Jobnet Monitor window opens, the information shown in the Jobnet Monitor window remains unchanged.

Monitor the latest status and results

The Jobnet Monitor window shows the latest status or result, regardless of the information displayed in the JP1/AJS3 - View window. With this option, the status or result of the most recent generation can be displayed when multiple generations are produced for the jobnet being monitored.

(3) Editor / Monitor page

Decide how to display units in the map area in the Jobnet Editor window and Jobnet Monitor window.

Unit name new line

Unit names in the map area of the Jobnet Editor window and Jobnet Monitor window are wrapped after the 10th character. This can make it difficult to see the unit status and operation result in the Jobnet Monitor window. By setting a different position for wrapping unit names, you can make them easier to read. Decide the wrap position as required, bearing in mind the naming conventions for unit names.

Display comments

To display a comment under a unit name, specify the number of characters from the beginning of the comment. Comments are displayed in the specified number of characters.

If you do not want to display a comment, specify a control character at the beginning of the comment. Comments beginning with the control character do not appear in the map area.

Displaying rules such as the processing cycle of a job or jobnet as a comment makes units easier to manage. Also, entering Japanese processing names as multi-byte characters within the 80-byte limit is useful.

You can also check the contents of a comment without having to open the dialog box for defining a job or jobnet.

If you select No on this page, you can still display comments using the tool tips.

Highlighted display

When highlighting is specified in the Jobnet Editor window or Jobnet Monitor window, you can set the display colors for the base unit, preceding and subsequent units, and relationship lines.

Double-click in unit

You can select either of the following as the behavior when you double-click a unit in the list area of the Jobnet Editor window or Jobnet Monitor window:

Display the Define Details - [unit-conname] dialog box in the Jobnet Editor window, and the Monitor Details - [unit-conname] dialog box in the Jobnet Monitor window.

Display the double-clicked unit in selected status in the middle of the map area.

(4) Schedule page

Decide the following settings for calculating execution schedules and displaying the Daily Schedule window:

First execution time

The first execution time is used to calculate the scheduled end time when a jobnet or job is executed for the first time. The scheduled end time of subsequent runs is calculated from the average of the previous execution times of the jobnets or jobs.

By entering the expected execution time in advance, you can check the scheduling behavior and results of a test run, using an execution time that simulates actual operation. You can specify a first execution time of between 1 and 86400 (seconds). The default is 1200.

Daily display time

You can select whether to display schedules in the time area of the Daily Schedule window over a 24-hour period (today) or 48-hour period (today and tomorrow). When a schedule such as batch execution of mass data runs over a two-day period (across a date boundary), 48-hour display makes the execution schedule and results easier to see.

Simulation

You can select whether to use the monthly execution simulation function. This function calculates the execution schedule of a jobnet registered for planned execution and displays the result in the Monthly Schedule window.

The next execution schedule of a jobnet registered for planned execution is normally calculated when the jobnet starts. When using the monthly execution simulation function, all the execution schedules are calculated when the jobnet is registered, based on the registration and execution information, and the definition information at that point in time. Set this option to check the start time and operation of an execution schedule in a manner that approximates actual operation.

Order display by:

Select the order in which unit names are listed in the tree area of the Daily Schedule window and Monthly Schedule window. Units can be listed by name or by execution time.

When listed by name, the units appear in ascending order. The sorting order depends on the character encoding specified for JP1/AJS3 - Manager. Select the Name option when unit names are assigned by work task, department, or process and you want to view execution schedules and results for a particular work task, department, or process.

When listed by execution time, the units appear in ascending order, starting from the oldest execution start time. Select the Execution time option when you want to view unit execution schedules in chronological order.

Root jobnet with no schedule (Daily (hierarchy) / Monthly)

Select whether to display planning groups, and root jobnets without any schedule information, in the tree area of the Daily Schedule (Hierarchy) window and Monthly Schedule window.

By selecting the Display option, you can view all the root jobnets in a job group, even if not registered for execution.

The Display option also shows all the jobnets in a planning group, including those without any schedule information (not yet scheduled). Select Display when you want to check what kind of jobnets a planning group contains.

Planning group

The schedule information of all units in a planning group can be merged when displayed in the schedule area of the Monthly Schedule window. Select the Display option when you want to view the jobnets in a planning group as if they were a single jobnet.

(5) General page

Decide how to color-code the status of units displayed in the windows. There is no need to do so when using the default colors. Consider color mapping only if you want to change the colors from the defaults, or if you want to create your own colors and use them to display statuses.

Change icon color

For details about how to create colors, see 11.3.3 Creating colors for execution status, execution results, and delays in the JP1/Automatic Job Management System 3 Operator's Guide.

Priority of delay display color

You can prioritize the color display when a unit terminates with two or more end statuses (end abnormally, end with warning, and/or end delay). Select one of the following options:

Abend > Warning > Delay

The color priority is abnormal end, end with warning, and end delay, in that order.

Abend > Delay > Warning

The color priority is abnormal end, end delay, and end with warning, in that order.

Delay > Abend > Warning

The color priority is end delay, abnormal end, and end with warning, in that order.

For example, with Abend > Warning > Delay selected, a jobnet that ends abnormally and with a delay will appear light red, the color for abnormal end. But with Delay > Abend > Warning selected, the jobnet will be orange, the color for end with delay.

Select an option according to how highly you want to prioritize end delays in monitoring the system. Select Delay > Abend > Warning if you want to give highest priority to monitoring for end delays, which affect work task execution as a whole.

Hold plan

On the General page you can also specify whether to use the Hold plan color for the unit icon and in the Status and Result columns when a unit is in held status and its hold attribute has been set.

(6) Other page

Decide the settings for JP1/AJS3 - View log files, which contain a history of operations performed in JP1/AJS3 - View. Set the trace level and the maximum file size.

Trace level

Select the level of information to be output to a log file. You can select 1, 3, or 5. Setting a higher level means that more detailed information and more log entries will be output. Log files might need to be swapped in and out frequently, reducing processing speed on the JP1/AJS3 - View host. Select 3 or 1 if you do not want processing to slow down.

The default is 3.

Trace levels are as follows:

Trace level 1

Outputs error information.

Trace level 3

Outputs error information, and information identifying what operation the user was performing.

Trace level 5

Outputs error information, information identifying what operation the user was performing, and information about the content of sent and received data.

Max. log file size

You can specify a maximum log file size, as a value from 1 to 512 (megabytes). When the log file reaches the specified size, a second log file is created automatically. The second log file will be the same maximum size. When the data in the second log file reaches the specified size, the first log file is overwritten.

For details about estimating the log file size, see 3.4.4 Estimating the size of log files for JP1/AJS3 - View.

Setting file

The View customization settings file (jajsCustomizeView) can be uploaded to the connection-destination manager host. If that file has already been uploaded to the connection-destination manager host, it can be downloaded. For details about the view customize setting file, see 11.3.19 Displaying the information about the connection-destination manager host in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.2 Common settings for JP1 users

This subsection describes how to use common settings for JP users (common user profile).

JP1/AJS3 can save (upload) the configuration information set in JP1/AJS3 - View to the JP1/AJS3 - Manager in which the user is logged in. This configuration information is called the common user profile. The common user profile is information that is common to all JP1 users. The following information is saved as a common user profile:

Settings in the Preferences dialog box

Settings in the ajs2view_opt.conf file

Default settings in dialog boxes

You can download the common user profile that is saved in JP1/AJS3 - Manager from JP1/AJS3 - View. If you download this profile, JP1/AJS3 - View is updated with the saved configuration information.

You can use the common user profile when:

You log in to JP1/AJS3 - Manager as a new JP1 user, and you want to use JP1/AJS3 - View with the same settings that other JP1 users use.

You want to customize the new JP1/AJS3 - View to use familiar settings.

We recommend that you use a common user profile to set up the JP1/AJS3 - View environment if you need to ease the task of setting up the environment for each JP1 user.

For details about the common user profile, see 11.1.2 Using common user profiles in the JP1/Automatic Job Management System 3 Operator's Guide.

(1) Setting the environment using common settings

The following figure shows the work flow when setting the environment using a common user profile.

Figure 4‒4: Example of using a JP1/AJS3 - View common user profile

(2) Notes on using common settings

Note the following when using common settings:

Users can upload and download common settings, and change the common settings saved on a JP1/AJS3 - Manager host, regardless of their JP1 user privileges or the rights of the mapped OS user. To allow only certain users to upload or download a common user profile, deactivate the menu commands. For details about how to do so, see 11.3.9 Disabling menus in the JP1/Automatic Job Management System 3 Operator's Guide.

The OS user mapped to a JP1 user who uploads a common user profile requires the write privilege (permission to write to a file). Grant the write privilege to the following folders:

Physical host (Windows):

JP1/AJS3-Manager-installation-folder\conf

Mgr_Path\conf\Profiles

Mgr_Path\conf\Profiles\(common)

The default Mgr_Path folder is as follows:

system-drive\ProgramData\HITACHI\JP1\JP1_DEFAULT\JP1AJS2

Physical host (UNIX):

/etc/opt/jp1ajs2/conf

/etc/opt/jp1ajs2/conf/Profiles

/etc/opt/jp1ajs2/conf/Profiles/(common)

Logical host (Windows):

shared-folder\jp1ajs2\conf

shared-folder\jp1ajs2\conf\Profiles

shared-folder\jp1ajs2\conf\Profiles\(common)

Logical host (UNIX):

shared-directory/jp1ajs2/conf

shared-directory//jp1ajs2/conf/Profiles

shared-directory//jp1ajs2/conf/Profiles/(common)

When multiple JP1 users update a common user profile, the JP1 user settings that were most recently uploaded take effect.

The OS user who downloads a common user profile (starts JP1/AJS3 - View) requires the write privilege (permission to write to a file). Grant the write privilege to the following folders:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2V\conf\JP1-user-name\ajs2view_opt.conf

By default, %ALLUSERSPROFILE% resides in system-drive\ProgramData.

4.5.3 Common settings for JP1/AJS3 - View hosts

This subsection describes how to use common settings for JP1/AJS3 - View hosts.

Settings information that is valid for a JP1/AJS3 - View host can be saved in a file and then applied to a host. This file is called the system common settings file.

For details about the system common settings file, see 11.1.1 Types of customization methods in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.4 JP1/AJS3 commands that can be executed from JP1/AJS3 - View

You can execute JP1/AJS3 commands not only from the manager host but also from JP1/AJS3 - View. Executing JP1/AJS3 commands from JP1/AJS3 - View allows you to collect the operating status and job definition information for JP1/AJS3 - Manager without logging in to the manager host. Before executing JP1/AJS3 commands from JP1/AJS3 - View, you need to determine some items and specify settings. This subsection describes points to consider when executing JP1/AJS3 commands from JP1/AJS3 - View.

(1) JP1/AJS3 commands for which execution from JP1/AJS3 - View is permitted

The following table lists the JP1/AJS3 commands executable from JP1/AJS3 - View.

Table 4‒11: JP1/AJS3 commands executable from JP1/AJS3 - View

No.

Command

Description

1

ajslogprint

Extracts and outputs information from the scheduler log.

2

ajsprint

Outputs the definition of a unit.

3

ajsshow

Outputs information about a unit, including the execution history, current status, and next scheduled execution.

4

ajsstatus

Outputs the operating environment of the scheduler service.

Use JP1/AJS3 - Manager to specify which of the above JP1/AJS3 commands are commands that JP1/AJS3 - View users are permitted to execute. Based on your operation needs, consider which JP1/AJS3 commands require permission to be executed from JP1/AJS3 - View.

For details about commands, see 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(2) JP1 users permitted to execute JP1/AJS3 commands

Consider which JP1 users should be permitted to execute which JP1/AJS3 commands. JP1/AJS3 commands to be executed from JP1/AJS3 - View must be defined in advance in an executable command settings file (jajsExecutableCommand) on the manager host. Creating this executable command settings file allows JP1/AJS3 commands to be executed from JP1/AJS3 - View. Depending on where the executable command settings file is stored, the settings in the file apply to all JP1 users or to an individual user.

The following figure shows how to store the executable command settings file.

Figure 4‒5: Storing the executable command settings file

If both the files for individual JP1 users and the common file for all JP1 users are stored, the files for individual JP1 users have precedence. The following figures show examples of setting executable command settings files.

Figure 4‒6: Example of setting executable command settings files (if a common file for all JP1 users has not been created)

Figure 4‒7: Example of setting executable command settings files (if a common file for all JP1 users has been created)

Cautionary note

If many JP1 users are permitted to execute JP1/AJS3 commands, multiple users might execute commands at the same time. This might increase the load on the manager host and affect JP1/AJS3 operations. Therefore, we recommend that you examine each JP1 user, and then specify commands for which execution from JP1/AJS3 - View is permitted.

For details about how to set executable command settings files, see 11.1.1 Types of customization methods in the JP1/Automatic Job Management System 3 Operator's Guide.

(3) JP1 user permissions

JP1/AJS3 commands are executed (from JP1/AJS3 - View) under the JP1 user's permissions that were used when the user logged in to the manager host from JP1/AJS3 - View. Therefore, confirm that the JP1 users who want to execute JP1/AJS3 commands from JP1/AJS3 - View have the permissions necessary to execute those commands.

For details about permissions necessary for executing JP1/AJS3 commands, see 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(4) JP1/AJS3 commands to be registered

To execute JP1/AJS3 commands from JP1/AJS3 - View, you need to register command arguments and execution-result output destinations in advance in JP1/AJS3 - View.

Registered information can be shared with other JP1 users by using a common user profile. Therefore, we recommend the following operation: First, the system administrator registers command arguments and execution-result output destinations, and then uploads the common user profile to the JP1/AJS3 - Manager host. Next, JP1 users download the common user profile.

Do not use wildcard characters or the -R option to specify a unit name. If you use them, many units are subject to processing and command execution might take a long time. If you need to use wildcard characters or the -R option, also use the -E, -L, or -T option to narrow down the target units.

For details about how to register commands, see 10.4.1 Registering JP1/AJS3 commands in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.5 Setting the window display

Decide after how many seconds you want to auto-refresh the JP1/AJS3 - View windows, and the timing for auto-saving information.

(1) Refresh interval

Decide whether to automatically refresh the unit status information displayed in the JP1/AJS3 - View windows.

You can specify auto-refresh for the JP1/AJS3 - View window, Daily Schedule window, and Jobnet Monitor window. The refresh interval can be set separately for each window. For example, you can set the refresh interval to 300 seconds for the JP1/AJS3 - View window, and 30 seconds for the Jobnet Monitor window. Set the refresh interval as a value from 30 to 3600 (seconds).

For details about setting the window refresh interval, see 11.4.2 Setting the window refresh interval in the JP1/Automatic Job Management System 3 Operator's Guide.

Refreshing windows increases the load on JP1/AJS3 - Manager. If the increased load is likely to affect the execution of work tasks, disable auto-refreshing or set a longer refresh interval, whichever is operationally appropriate.

If you prefer to refresh windows manually, choose View, and then Refresh to display the latest information.

(2) Save status setting

Decide whether to display the active window and current unit the next time JP1/AJS3 - View is started. This is the save status setting.

When the save status setting is enabled, the window and unit you are working on will be displayed the next time you start JP1/AJS3 - View. If you are creating a large-scale work task, this setting will save time in searching for the unit you want to work on.

For example, suppose you are using a terminal for monitoring work tasks. With the target unit displayed in the Jobnet Monitor window or Daily Schedule window, choose Options, Save Status, and then Save. The next time you log in, the saved status (active Jobnet Monitor window or Daily Schedule window) will be displayed, so you can monitor the target unit from the active window as soon as you log in. The displayed execution status and result, however, will be the unit's current status and result at the time JP1/AJS3 - View started.

When the save status setting is disabled, only the JP1/AJS3 - View window is displayed at startup, and only the root jobnet and the job groups directly under the root job group appear in the window.

Notes on enabling the save status setting

Information in dialog boxes and calendar information are not saved.

The item display widths in the list area of the JP1/AJS3 - View window are not saved.

The column width representing one day in the schedule area of the Monthly Schedule window is not saved.

The column width representing one hour in the schedule area of the Daily Schedule window is not saved.

The selected hierarchical view is saved in the JP1/AJS3 - View window, Jobnet Editor window, and Jobnet Monitor window, but not in other windows.

Information about a manager job group, manager jobnet, or remote jobnet displayed in the Jobnet Monitor window is not saved.

The minimized or maximized status of the displayed window is not saved.

Information about which window is active among the open windows is not saved.

When multiple instances of JP1/AJS3 - View are active, only the JP1/AJS3 - View in which the save status setting was enabled is displayed in saved status.

If you delete a unit displayed in a window, an error will occur when you next open the JP1/AJS3 - View window.

If you log in to a host other than the host where the window information was saved, the window is not displayed in the saved state.

4.5.6 Changing the dialog box defaults

In JP1/AJS3 - View, you can change the defaults for radio buttons and check boxes in the dialog boxes (except when the default is an empty text field or job type).

We recommend that you change the defaults in the following situations.

Table 4‒12: Examples of changing the defaults

Item and changed default

Reason for changing the default

In the Register of Execution dialog box, change the default of Planned time passed when daemon starts and Planned time passed when reg. for exe. from Execute immediately to Execute from next time.

To prevent the user from mistakenly executing the jobnet immediately by clicking the OK button when registering a jobnet for scheduled execution.

Change the jobnet's Priority default from None to 5 (nice value: -20).

To prioritize and finish the JP1/AJS3 process as soon as possible.

For details about how to change the defaults in a dialog box, see 11.3.6 Changing default values in dialog boxes in the JP1/Automatic Job Management System 3 Operator's Guide.

For details about the display items and defaults in each dialog box, see 12. Windows and Dialog Boxes in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.7 Adding display items to a window

You can add display items (columns) to the following areas in JP1/AJS3 - View:

List area in the JP1/AJS3 - View window (Main window)

Execution result list in the Daily Schedule window

Execution result list in the Monthly Schedule window

Search result list area in the Search window

List area in the Jobnet Editor window

List area in the Jobnet Monitor window

You can add items to these windows that you would otherwise have to check in another window or in the Monitor Details dialog box. This makes monitoring work more efficient.

The following figure shows an example of display items added in each area.

Figure 4‒8: Example of a window with additional display items

For details about how to change the display items, see 11.4.6 Specifying the columns displayed in the list area in the JP1/Automatic Job Management System 3 Operator's Guide.

For details about the display items that can be added and the dialog boxes, see 12.3.46 Display Item Setup dialog box in the JP1/Automatic Job Management System 3 Operator's Guide.

4.5.8 Considerations for multiuser remote desktop connections to JP1/AJS3 - View

With the default settings, only one user can use JP1/AJS3 - View via a remote desktop connection. If the multiuser remote desktop connection function is enabled, multiple users can use JP1/AJS3 - View via remote desktop connections.

The following figures show overviews of cases where the multiuser remote desktop connection function is disabled and where it is enabled.

Figure 4‒9: Overview of a case where the multiuser remote desktop connection function is disabled

Figure 4‒10: Overview of a case where the multiuser remote desktop connection function is enabled

If the multiuser remote desktop connection function is disabled, the entire JP1/AJS3 - View system uses the common environment settings and log file. However, if the function is enabled, the environment settings and log file are managed separately for each OS user. Because each OS user uses different files, an OS function can be used to set access permissions for these files so that the files of one OS user cannot be viewed by other OS users.

The following table describes the JP1/AJS3 - View functions that can be managed for each OS user when the multiuser remote desktop connection function is enabled.

Table 4‒13: Functions that can be managed when the multiuser remote desktop connection function is enabled

Function

Description

Login screen

User name

A login history is displayed for each OS user.

Host to connect

Preferences dialog box

Auto login#

Auto login

These items can be set for each OS user.

User name

Password

Host to connect

Troubleshooting#

Trace level

Max. log file size

JP1/AJS3 - View information log

Log data is output to a different folder for each OS user.

#

Environment settings other than those listed in this table are specified for each JP1 user.

The multiuser remote desktop connection function can be used regardless of the version of JP1/AJS3 - Manager to which you are connecting.

If the multiuser remote desktop connection function is enabled, the same custom jobs can be used by the entire system or different custom jobs can be used for each JP1 user.

Figure 4‒11: Overviews of cases where the same custom jobs are used by the entire system and where different custom jobs are used for each JP1 user

For details about how to enable the multiuser remote desktop connection function, see 11.2.7 Allowing multiple users to concurrently use JP1/AJS3 - View via remote desktop connections in the JP1/Automatic Job Management System 3 Operator's Guide. For details about how to use different custom jobs for each JP1 user, see 11.2.8 Allowing each JP1 user to use different custom jobs in the JP1/Automatic Job Management System 3 Operator's Guide.

Cautionary note

To enable the multiuser remote desktop connection function, use a different JP1 user for each OS user. Each OS user can use only one session of remote desktop connection to JP1/AJS3 - View at a time.

4.6 Environment settings for JP1/AJS3 - Web Console

This section describes the settings involved in setting up JP1/AJS3 - Web Console.

Setting up JP1/AJS3 - Web Console includes setting environment settings on the Web Console server (a host on which JP1/AJS3 - Web Console is installed) and on the JP1/AJS3 - Manager that is connected to the Web Console server. Decide whether to use the defaults or customized settings for each of the hosts.

For details about specifying these settings, see the JP1/Automatic Job Management System 3 Configuration Guide.

4.6.1 Environment settings for the Web Console server

This subsection explains Web Console server environment settings that need to be considered in advance.

(1) Log sizes and the number of log files output by the Web Console server

The Web Console server outputs the following three types of log data:

Command log

Outputs log data about command operations.

Application server log

Outputs log data about Web GUI operations or API calls from user applications.

Application server common log

Outputs log data about the starting and stopping of the web application server.

The following table lists the default sizes and the number of files for each type of log.

Table 4‒14: Default sizes and the number of files of the log data output by the Web Console server

No.

Log type

Default size

Default number of files

1

Command log

128 kilobytes

2

2

Application server log

8,192 kilobytes

2

3

Application server common log

8,192 kilobytes

2

For the command log and application server log, you can change the size and the number of files of the log data. The size and the number of files for the application server common log cannot be changed.

The log size and the number of files for the command log and application server log are specified in the environment-settings file (ajs3web.conf). For details about the environment-settings file (ajs3web.conf), see the section corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

(2) Time zone of the Web Console server

The date and time information on the Web GUI or a user application is displayed according to the manager host time zone regardless of the client host time zone. Therefore, if the Web Console server and the manager host have different time zones, you need to specify the manager host time zone in the environment-settings file (ajs3web.conf) on the Web Console server.

The following figure shows example time zones of the Web Console server and manager hosts.

Figure 4‒12: Example time zones of the Web Console server and manager hosts

In this example, the time zone of the Web Console server is JST, time zones of the manager hosts from A to C are JST, Asia/Shanghai, America/New_York, respectively. The time displayed on the Web GUI is the time zone of the corresponding destination manager host.

If you connect to the manager host A, setting the environment-settings file (ajs3web.conf) is not required. If you connect to the manager host B or manager host C, you need to set the time zone in the environment-settings file (ajs3web.conf). This is because the time zone of the manager host and that of the Web Console server do not match.

By using the ajswebtz.bat command (in Windows) or the ajswebtz command (in Linux), you can obtain a list of time zones that can be specified in the environment-settings file (ajs3web.conf). For details, see ajswebtz.bat (Windows only) in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference or ajswebtz (Linux only) in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

For details about the environment-settings file (ajs3web.conf), see the section corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

(3) Changing display colors for the Web GUI

The following discusses the colors that indicate the statuses of units displayed in the windows and dialog boxes of the Web GUI. You can change the display colors by changing settings in the display color settings file (ajs3web_color.conf) on the Web Console server.

For details about the display color settings file (ajs3web_color.conf), see the section corresponding to the OS. For Windows, see 3.4.8 Details on the settings in the display color settings file (ajs3web_color.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For Linux, see 13.3.8 Details on the settings in the display color settings file (ajs3web_color.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

Changing the display colors that indicate unit statuses

You can change the colors that indicate the statuses of units displayed in the windows and dialog boxes of the Web GUI. The following table lists the windows and dialog boxes in which display colors can be changed, and the items whose display colors can be changed. Note that, for icons, you can change the background color only.

Table 4‒15:  Items whose display colors can be changed by editing the display color settings file (ajs3web_color.conf)

No.

Screen and Dialog box

Items whose display colors can be changed

1

Dashboard screen

Status of Root Jobnet area

Execution progress (for individual root jobnets)

2

Root jobnet status icons

3

Execution progress (for the whole units)

4

Unit status icons

5

Detail Information area

List tab

Icons in the Status column

6

Icon for the Hold-On button

7

Icon for the Hold-Off button

8

Chart tab

Execution schedule

9

List screen

List area

Icons in the Status column

10

Icons in the Result column

11

Monitor dialog box, Monitor screen

Map area

Icons for the Unit

12

Top of the screen and dialog box

Icon for the Hold-On button

13

Icon for the Hold-Off button

14

Icon for the Interrupt button

15

Icon for the Kill button

16

Icon for the Rerun button

17

Generation Selection dialog box

Icons in the Status column

18

Monthly Schedule screen

Schedule area

Execution schedule

19

List area

Icons in the Status column

20

Top of the screen

Icon for the Hold-On button

21

Icon for the Hold-Off button

22

Wait Conditions Statuses dialog box

List area of units with wait conditions

Icons in the Status column

23

List area of units whose end is being waited for

Icons in the Status column

Setting to use the same display colors for the Web GUI and JP1/AJS3 - View

By using the model file ajs3web_color_view.conf.model, you can set the display colors for the Web GUI to the default display colors for JP1/AJS3 - View. If display colors for JP1/AJS3 - View were changed from the defaults, those colors can be also set for the Web GUI. To do this, change definitions in the display color settings file (ajs3web_color.conf).

Display color for the delay

For units in the Delay status, you can specify whether to have the status displayed as the color for its icon, status, or result.

You can also use the DELAY_COLOR_PRIORITY parameter in the display color settings file (ajs3web_color.conf) to specify which status color to display for a unit if the status of the unit is simultaneously Abend, Warning, or Delay. You can specify the following values:

A-W-D

The priority for the displayed color is Abend > Warning > Delay.

A-D-W

The priority for the displayed color is Abend > Delay > Warning.

D-A-W

The priority for the displayed color is Delay > Abend > Warning.

For example, if you specify A-W-D and a jobnet ends abnormally due to a delay, the color for abnormal ends (light red) is displayed. If you specified D-A-W, the color for delayed ends (cherry blossom color) is displayed.

Select a priority according to the importance placed on delays when monitoring the system. The default is A-W-D. To prioritize the monitoring of delays in units whose execution impacts the business as a whole, specify D-A-W.

Hold plan

You can specify whether to use the color for Hold plan for unit icons and color images in the Status and Result columns if a unit is in a wait status and its hold attribute has been set. The wait status is Wait for start time, Wait for prev. to end, Waiting to execute, or Wait for start cond.

(4) Settings for restricting the operations that Web GUI users can perform

You can restrict the operations that can be performed by each JP1 user who logs in to the Web GUI.

To restrict the operations that users can use the Web GUI to perform, first, change the following two settings in the environment settings file (ajs3web.conf) on the Web Console server:

Enable the operation restriction function

Enable the operation restriction function, which is disabled by default. If the operation restriction function is enabled on a Web Console server, the function is available on all manager hosts to which the Web Console server connects. Immediately after this function is enabled, the default setting (permit only viewing) is applied to all users.

Specify a user who can set operational restrictions

Specify a JP1 user who can change the operation restriction settings of individual JP1 users for each manager host to which a connection is to be established. This JP1 user is referred to as a user who sets permissions.

A user who is appointed as a user who sets permissions can set operational restrictions for each JP1 user by applying the operating permission configuration file from the Web GUI. Note that you must apply the operating permission configuration file to each manager host to which a connection is to be established.

For details about environment-settings file (ajs3web.conf), see the sections corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For Linux, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

For details about the operating permission configuration file, see 17.2.2 Customizing the operation restriction settings for each user in the JP1/Automatic Job Management System 3 Operator's Guide.

The following table lists the operations that can be restricted by using the operating permission configuration file.

Table 4‒16: Operations that can be restricted by using the operating permission configuration file

No.

Operation that can be restricted

Description

1

Register for Execution

Registers a unit for execution.

2

Cancel Registration

Cancels the execution registration of a unit.

3

Adding an execution schedule

Schedules a unit to run at a specified time.

4

Change plan (change time)

Temporarily changes the start time of a unit that has been registered for execution.

5

Change plan (execute immediately)

Temporarily changes the execution schedule of a unit that has been registered for execution so that the unit is executed immediately.

6

Change plan (execution prohibited)

Temporarily changes the execution schedule of a unit that has been registered for execution so that execution of the unit is canceled.

7

Change plan (release change)

Restores the execution schedule of a unit whose execution schedule was temporarily changed.

8

Change Delay Monitor

Temporarily changes the delay monitoring settings of a unit that has been registered for execution.

9

Rerun

Reruns a unit that has already been run.

10

Interrupt

Interrupts the execution of a unit.

11

Kill

Kills the execution of a unit.

12

Change job status

Changes the job status.

13

Edit definition

Lets you edit the detailed definition of a job (PC job or Unix job only).

14

Hold

Sets the hold attribute of the unit.

15

Hold Release

Cancels the hold attribute of the unit.

16

Execution Order Method

Changes the execution order control method to the synchronous method or asynchronous method.

17

Waiting

Enables or disables unit waiting.

(5) Settings on manager hosts to which the Web Console server can connect

Determine the manager hosts to which the Web Console server can connect. You can restrict the manager hosts to which the Web Console server can connect by changing the settings in the environment settings file (ajs3web.conf) on the Web Console server.

For details about environment-settings file (ajs3web.conf), see the sections corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For Linux, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

Manager hosts to which the Web Console server can connect

The Web Console server can connect to only those manager hosts whose names are specified in the environment settings file (ajs3web.conf). With the default settings, any management host is connectible. You can specify the following names as manager host names:

In physical host:

Host name that is output when the hostname command is run on a manager host

In logical host:

Logical host name that was specified when the logical host environment was set up

Method of specifying a value for [Host to connect] that appears in the Web GUI login screen

If the connectible manager hosts are restricted, you can change the Host to connect item appearing in the Web GUI login screen into a drop-down list that displays only the manager hosts that the user can connect to. By default, the Host to connect item is displayed as a text box in which the user enters the name of the connection-destination host.

Linkage with JP1/IM

To link JP1/AJS3 - Web Console with JP1/IM, you must permit connections to the JP1/AJS3 manager host that is to be monitored by JP1/IM.

(6) Restricting execution of API functions from user applications

In JP1/AJS3 - Web Console, API functions can be used to perform operations on units from user applications. You can also restrict execution of API functions by changing the settings in the environment settings file (ajs3web.conf) on the Web Console server. The default is that there are no restrictions. If restriction on execution of API functions is enabled, the users cannot run any API functions from user applications.

For details about environment-settings file (ajs3web.conf), see the sections corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

(7) Setting whether to display information about the connection-destination manager host

Consider whether the host name, OS, and other information about the connection-destination manager host is to be displayed from the Web GUI. Information about the connection-destination manager host can be displayed from the Web GUI by changing the settings in the environment setting file (ajs3web.conf) on the Web Console server. The user can specify the information items to be displayed. If information about the connection-destination manager host is displayed from the Web GUI, the background color of the display areas and the font color can be changed.

The following figure shows an example of a window that displays information about the connection-destination manager host from the Web GUI.

Figure 4‒13: Example of a window that displays information about the connection-destination manager host from the Web GUI

For details about environment-settings file (ajs3web.conf), see the sections corresponding to the OS. For Windows, see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

Information about the connection-destination manager host displayed from the Web GUI:

Information about the connection-destination manager host can be displayed in a window from the Web GUI by specifying the information about the connection-destination manager host in the environment setting file (ajs3web.conf). By default, this information is not displayed. If the user can connect to multiple manager hosts from the Web GUI, the host name, OS, and other information about the connection-destination manager host will help the user connect to the correct manager host.

Background and font colors of the area that displays information about the manager host from the Web GUI

You can change the background color of the area that displays information about the connection-destination manager host and the font color of the information to be displayed. The Web GUI user can easily identify the connection-destination manager host by changing the background color of the display area for each manager host that the user can connect to. Note that some combinations of background and font colors might affect the readability of text. If you change the background color of the area that displays information about the connection-destination manager host, select a font color that is easy to read on the background color.

(8) Setting the session timeout period for the Web GUI

Consider the proper session timeout period for the Web GUI. You can specify the session timeout period for the Web GUI by changing the setting in the environment settings file (ajs3web.conf) on the Web Console server. The default is 15 minutes.

For details about environment-settings file (ajs3web.conf), see 3.4.3 Details on the settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 13.3.3 Details on settings in the environment-settings file (ajs3web.conf) in the JP1/Automatic Job Management System 3 Configuration Guide.

4.6.2 Environment settings for JP1/AJS3 - Manager connected with a Web Console server

This subsection explains JP1/AJS3 - Manager environment settings that influence connections to and operations of the Web Console server. Consider changing the settings if necessary.

(1) Maximum number of concurrent sessions on the Web Console server

When JP1/AJS3 - Manager communicates with the Web Console server, the Web Console server creates a communication object used to connect with the scheduler service of JP1/AJS3 - Manager. For each object, the Web Console server and JP1/AJS3 - Manager connect with the scheduler service and establish a session. The maximum number of sessions that can be established at the same time can be set for each manager host. The default maximum number of concurrent sessions is 32.

Many sessions involve many processes, which can place a heavy load on JP1/AJS3 - Manager. To restrict such loads, determine the maximum number of concurrent sessions.

For details, see 20.4.2(21) CDMAXSESSION in the JP1/Automatic Job Management System 3 Configuration Guide.

(2) Timeout period for Web Console server connections

You can specify a certain period of time after the last communication at which the connection between JP1/AJS3 - Manager and the Web Console server times out. The default period is 3 minutes.

For example, if a user cannot log out from the server due to problems such as a communication failure, the session will be kept even if there is no communication. In such a case, the connection is automatically disconnected and the session is released if a timeout period has been specified.

Note that a long timeout period causes a non-active session to remain for a long time, and might cause the maximum number of concurrent sessions to exceed the limit. Determine the timeout period in view of the maximum number of concurrent sessions.

For details, see 20.4.2(104) CDSESSIONTIMEOUT in the JP1/Automatic Job Management System 3 Configuration Guide.

(3) Reusing logon information and the number of sessions that share the logon information when desktop heap shortages occur

The desktop heap area might be insufficient if there are many sessions on the manager host that are executed after being mapped to the same OS user. In this case, reusing the logon information for each session can reduce the desktop heap usage.

If desktop heap shortages occur, change the settings so that the logon information is reused. Also consider the number of shared sessions, if you reuse the logon information.

For details, see 20.4.2(12) REUSELOGON in the JP1/Automatic Job Management System 3 Configuration Guide and 20.4.2(13) LOGONSHMAX in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Changing this setting will also change how session processes are started in operations such as connecting to JP1/AJS3 - View and remotely executing a command.

(4) Output from the scheduler log

You can specify whether to output, to the scheduler log of JP1/AJS3 - Manager, the start and end messages for connections from the Web Console server to the scheduler service. By default, the messages are not output to the scheduler log. Specify the setting that suits your operations.

For details, see 20.4.2(16) MONLOG in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Changing this setting will also change the settings of whether to output connection-start messages and connection-end messages for connections with JP1/AJS3 - View.

(5) Outputting start and end messages

You can specify whether to output, to the following logs in JP1/AJS3 - Manager, the start and end messages for services that accept connections from the Web Console server.

In Windows:

Windows event log

Integrated trace log

In UNIX:

syslog

Integrated trace log

By default, the messages are output to the logs. We recommend that you keep this default setting because you need this log data to track down the cause of a failure.

The following table lists the process for which messages are output and their timings.

Table 4‒17: Process for which messages are output to the log and the output timing

No.

Process

Output timing

1

ajscdinetd

Start

2

End

For details, see 20.4.2(17) MONSYSLOG in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Changing this setting will also change the settings of whether to output connection-start messages and connection-end messages for the ajsinetd process, the ajscdinetd process, and JP1/AJS3 - View.

(6) Size of the internal log

You can specify the size of the internal log messages of JP1/AJS3 - Manager.

The following table lists the types of processes for which internal log data is output, and the default size of the log messages.

Table 4‒18: Types of processes for which internal log data is output and their default size

No.

Type of process that outputs messages to the internal log messages

Default size

1

ajscdinetd

128 kilobytes

2

ajsmonsvr

4,096 kilobytes

For details about the log size of the ajscdinetd internal log, see 20.4.2(22) AJSCDINETDLOGSIZE in the JP1/Automatic Job Management System 3 Configuration Guide. For details about the log size of the ajsmonsvr internal log see 20.4.2(105) CDMONSVRLOGSIZE in the JP1/Automatic Job Management System 3 Configuration Guide.

(7) The range of generation information

When you use the Web Console server to obtain the generation information of a unit, select one of the following date ranges for which information is obtained. The default value is all.

all

Specifies that information is to be obtained from generations that are executed or scheduled to be executed, on all dates.

today

Specifies that information is to be obtained from generations to be executed, on that day in the range of the base time.

If the valid range of the root jobnet schedule is set to 48 hours, the range of the generation information cannot be set to today.

For details, see 20.4.2(70) VIEWSTATUSRANGE in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Changing this setting will also change the range of the generation information that is obtained by JP1/AJS3 - View.

(8) Issuing JP1 events

You can specify whether to issue a JP1 event when a unit is manipulated by the Web Console server. By default, a JP1 event is not issued. Change the setting according to your operation.

For details, see 20.4.2(85) COMMANDEVENT in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Changing this setting will also change the settings of whether a JP1 event is to be issued when a unit is manipulated from JP1/AJS3 - View.

(9) Executing a jobnet whose scheduled execution start time has passed

You can use options for planned execution registration to specify how a jobnet is to be executed if the scheduled execution start time for the jobnet has already passed when the service starts or when the jobnet is registered for execution.

4.7 Settings for the user environment

This section describes what to consider in regard to setting user preferences.

4.7.1 Modifying the login script (UNIX only)

In the UNIX version of JP1/AJS3, the shell executes the login script of the execution OS user before execution of a standard job, HTTP connection job, action job, or custom job. # The following shows examples of executing shell login scripts:

#

There might be some differences depending on the OS type. For details, check the documentation for the applicable OS.

sh and ksh shells

/etc/profile
$HOME/.profile

csh shell

/etc/csh.login
$HOME/.cshrc
$HOME/.login

bash shell

/etc/profile
$HOME/.bash_profile

Text other than job execution results is output to the standard output file if the login script includes a command such as echo or cat that outputs data to the standard output. Also, if the stty, tty, tset, script, or other interactive command is executed in a batch file, the job might terminate abnormally. In this case, modify the login script so that such commands are not executed. For details about modifying a login script, see 13.4.2 Changing the login scripts in the JP1/Automatic Job Management System 3 Configuration Guide.

5 Contingency Planning

This chapter discusses the preventive measures required in JP1/AJS3.

JP1/AJS3 requires backups and redundancy as preventive measures. It is vital to plan such measures in advance so that the system can be restored with little impact should an unpredictable event occur.

5.1 Preparing for failures

Problems might arise for a variety of reasons (JP1/AJS3, user program, OS, operator error, and so on).

In case such problems occur, we recommend that you complete the following preparation before you start running JP1/AJS3.

Prepare a data collection tool

Check the JP1/Base, JP1/AJS, and OS versions

5.1.1 Preparing a data collection tool

JP1/AJS3 provides data collection tools for collecting information when a problem occurs.

The following table lists the data collection tools provided by JP1/AJS3.

Table 5‒1: JP1/AJS3 data collection tools

OS

Data collection tool

Customization

Windows

jajs_log.bat

N

_04.bat

Y

UNIX

jajs_log

N

_04

Y

Legend:

Y: Can be customized.

N: Cannot be customized.

If the default output destination of, for example, log files has not been changed, you can use jajs_log.bat or jajs_log to collect data. If the default output destination has been changed, customize _04.bat or _04 to collect data.

If a problem occurs in Windows, a dump file might be necessary for troubleshooting. Before you start operation, we recommend that you specify a setting so that a dump file is output if a problem occurs. For details about how to customize the Windows data collection tool (_04.bat) and how to set up output of dump files, see 7.1 Collecting log data in the JP1/Automatic Job Management System 3 Configuration Guide. For details about how to customize the UNIX data collection tool (_04), see 16.1 Collecting log data in the JP1/Automatic Job Management System 3 Configuration Guide.

If you cannot run the data collection tool, you can collect data manually. For the data that needs to be collected, see 1.3 Data to be collected when a problem occurs in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Before any problems occur, make sure that you can collect data successfully using the data collection tool.

5.1.2 Check the JP1/Base, JP1/AJS, and OS versions

To investigate the cause of a failure, you will need version information for JP1/Base, JP1/AJS, and the OS. When using support services, resolving the issue quickly depends on having a good understanding of the environment in which the problem occurred.

5.2 Backups and recovery

One of the system administrator's important responsibilities is to perform backup in case the system is damaged or an unexpected event occurs, such as the following:

The disk is damaged and JP1/AJS3 does not work.

A jobnet is mistakenly deleted and the original settings are lost.

A JP1/AJS3 file is inadvertently erased by an OS operation.

These sorts of situations can occur in any system. By backing up JP1/AJS3 information in advance, you can minimize their effects. Prepare and implement a backup plan. As well as deciding on some backup procedures, you must also consider recovery methods and make sure the system can actually be restored.

This section describes how to back up and restore a system that uses JP1/AJS3. Based on the following descriptions, consider what JP1/AJS3 backup and recovery procedures to implement as part of a system-wide backup plan.

5.2.1 Backup and recovery methods

To perform backup and recovery for JP1/AJS3, you need to back up and restore the settings information needed to run JP1/AJS3. The files to be backed up and the timing of a backup differ according to the purpose of the backup and recovery. Table 5-2 describes the types of backup and recovery and their characteristics.

You can use the following methods for backup and recovery are available:

Backing up and restoring specific settings information according to the update time.

Backing up and restoring the entire system or the shared disk in a cluster configuration in one operation.

Backing up and restoring the data of an embedded database in one operation.

After considering the advantages and disadvantages of each type of backup and recovery for the intended purpose, consider the time required for performing backup and recovery and the scope of backup and recovery.

Table 5‒2: Types of JP1/AJS3 backup and recovery and the characteristics of each

Type of backup and recovery

Main purpose

When backup is created

Advantages

Disadvantages

JP1/AJS3 environment settings information

Recovery from a failure such as a disk failure, a corrupted file, or files that are no longer available

When a setting is changed

JP1/AJS3 operation does not need to stop.

The time at which the backup is created and its scope can be set appropriately as needed.

For definition information and schedule information that is changed often, the timing of backups and the number of backups must be considered.

Because jobnets must be registered again, resuming work task takes a long time.

JP1/AJS3 definition information:

Definition information for jobs and jobnets

Calendar and schedule information

Execution agent information

Execution environment for QUEUE jobs and submit jobs

Recovery from a failure such as a disk failure, a corrupted file, or files that are no longer available

Distribution to other computers or scheduler services

Registered execution-schedule information for jobnets#1

Recovery from a failure such as a disk failure, a corrupted file, or files that are no longer available

When a jobnet is registered

Because the registration status of jobnets can be restored in one operation after recovery, the re-registration of individual jobnets is not required, reducing the workload before operation starts.

Jobnets registered for immediate execution are not included.

Entire system

Maintenance or migration of the entire system

When maintenance of the entire system is performed

When the entire system is migrated#2

Information can be backed up or restored in one operation.

JP1/AJS3 must be stopped during maintenance.

After recovery, JP1/AJS3 must be cold-started.#3

Because the jobnets must be registered again, time is required before work tasks resume.

Shared disk in a cluster configuration

Maintenance such as replacing the shared disk

Migration of a cluster system or reconstruction of an environment

Recovery from a shared disk failure

When cluster system maintenance is performed

Database (embedded database)

Recovery from a failure such as a failure on the disk containing the database, a corrupted file, or files that are no longer available

Migration of a system or reconstruction of the environment

When a setting change that requires the JP1/AJS3 service to stop or maintenance of the entire system is performed

The scheduler service must be stopped.

After the recovery, JP1/AJS3 must be cold-started.#3

Because the jobnets must be registered again, time is required before work tasks resume.

Recovery from a failure such as a failure on the disk containing the database, a corrupted file, or files that are no longer available

Daily or weekly

When the operation is changed, such as when a jobnet is registered

JP1/AJS3 operation does not need to stop.

Information can be backed up or restored in one operation.

JP1/AJS3 does not need to be cold-started after restoration.

Configuration is required during setup of the embedded database.

#1

To back up and restore the registered execution-schedule information, you also need to back up and restore the unit definition information.

#2

When an entire system is migrated via backup and recovery, JP1/AJS3 - Manager cannot be migrated to a host that has a different host name. JP1/AJS3 - Manager can only be migrated to the same host or to another host that has the same host name. JP1/AJS3 - Agent can be migrated to a host that has a different host name.

In either case, as a prerequisite, JP1 must back up the entire system while maintaining the integrity of all file information, including the information registered in the OS, and then must restore all the backed up files.

If you intend to back up and restore an entire system using OS commands and backup tools, first verify the environment that is being used.

#3

When JP1/AJS3 is cold-started, the registered execution-schedule information for jobnets and the execution information for jobnets and jobs are initialized, and can no longer be restored.

(1) Backing up and restoring JP1/AJS3 environment settings information and definition information

(a) What needs to be backed up and restored

You should back up files containing JP1/AJS3 environment settings information and definition information, and the settings information output by using a JP1/AJS3 command. The JP1/AJS3 environment settings and definition information includes information about JP1/AJS3 - Manager, JP1/AJS3 - Agent, and JP1/AJS3 - View. For details about the information that must be backed up in JP1/AJS3, see Table 5-4 in 5.2.2 Target files and backup timing.

Note that the definition information for jobnets and jobs, calendar and schedule information, and execution agent definition information are stored in an embedded database. Determine the unit and the best time to perform backup and recovery according to operational needs.

(b) Backup and recovery procedures

For details about the backup procedure, see 2.2.1(1) Backup procedure in the JP1/Automatic Job Management System 3 Administration Guide.

When you perform recovery, restore the backed up information to the system as needed according to the state of the system after a failure. Because only the settings information needed to run JP1/AJS3 is backed up, you will need to re-register jobnets for execution after this information is restored. For details about the recovery procedure, see 2.3.1(1) Recovery procedure in the JP1/Automatic Job Management System 3 Administration Guide.

(c) Backup and recovery methods

For details about how to back up and restore only settings information, see 2.2 Backing up the setup information for a system that uses JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide and 2.3 Restoring the setup information for a system that uses JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

(2) Backing up and restoring registered execution-schedule information for jobnets

You can use the functions for exporting and importing registered execution-schedule information to back up and restore the execution registration status for jobnets. If a failure occurs in the JP1/AJS3 system or if you need to cold-start the JP1/AJS3 service in order to back up and restore the entire system, these functions greatly reduce the time required until operation resumes.

You can back up and restore the registered execution-schedule information for jobnets in JP1/AJS3 - Manager. For details, see 3.4 Backing up and recovering the execution registration status of jobnets by using the ajsrgexport and ajsrgimport commands in the JP1/Automatic Job Management System 3 Administration Guide.

(3) Backing up and restoring the entire system

(a) Backup and recovery methods

When you use an OS command or backup tool to back up the entire system, stop JP1/AJS3 before starting the backup process. To restore the system from the backup, cold-start JP1/AJS3 to initialize the registered execution-schedule information for jobnets and the execution information for jobnets and jobs. For details about the procedure, see 2.4 Backing up and recovering an entire system in the JP1/Automatic Job Management System 3 Administration Guide.

(b) Considerations before backing up or restoring the entire system

Consider the following before you back up or restore the entire system:

Consistency with other data and applications (for example, the status of user jobs)

To what state (the point in time) you want to restore the jobnet or job

Which host (the manager host or the agent host) will be cold-started

With products such as JP1/AJS3, which link to a variety of other programs, it is extremely difficult to ensure consistency for the execution status and results of jobnets and jobs, and of executed user jobs. Consistency might be achievable, but only by imposing various constraints on the user jobs executed in the system. That contradicts the main JP1/AJS3 purpose of the flexible management of program operations through the use of jobnets. For these reasons, we recommend that you limit backup and recovery procedures to the JP1/AJS3 environment settings information and definition information.

(4) Backing up and restoring the shared disk in a cluster configuration

(a) Backup when replacing the disk

A shared disk used in a cluster configuration might need to be replaced to avoid hardware failures due to aging of the disk or another problem. In such cases, stop JP1/AJS3, copy the shared disk, and then replace the disk.

To back up or recover an entire shared disk, you must also back up or recover the entire system, including local disks.

(b) What needs to be backed up and restored and methods

If you want to be able to restore shared-disk data in the event of a failure, you need to back up the information described in (1) Backing up and restoring JP1/AJS3 environment settings information and definition information for each logical host in advance.

To back up and restore the physical host environment for a cluster configuration, you need to perform backup and recovery on both the executing and the standby hosts. For a logical host environment, you need to perform backup and recovery only on the executing host. You can then use the information you backed up on the executing host to restore the standby host.

For an overview of backup for a cluster configuration, see 2.2.1(2) Backup procedure (when a cluster system is used) in the JP1/Automatic Job Management System 3 Administration Guide. For an overview of recovery, see 2.3.1(2) Recovery procedure (when a cluster system is used) in the JP1/Automatic Job Management System 3 Administration Guide.

For details about the types of folders processed when you back up or restore the shared disk in a cluster configuration, see 8.2.1(1) Creating shared files on the shared disk in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 17.2.1(1) Creating shared files on the shared disk in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

For details about how to back up and restore the shared folder, see the procedures for logical hosts in 2.2.3 Backing up the JP1/AJS3 - Manager setup information in the JP1/Automatic Job Management System 3 Administration Guide and 2.3.4 Recovering the JP1/AJS3 - Manager setup information in the JP1/Automatic Job Management System 3 Administration Guide.

(5) Backing up and restoring an embedded database

Embedded databases are classified as scheduler databases and agent management databases. A scheduler database contains definition information for jobnets and jobs, calendar and schedule information, and execution status and execution results for jobnets and jobs. An agent management database contains execution agent information.

You can back up and restore an embedded database in JP1/AJS3 - Manager. The available methods for backing up and restoring an embedded database are as follows:

Backup and recovery by using the backup enhancement function

Backup and recovery by using unload log files (unload log operation)

Backup and recovery without using the system log

The following table provides an overview of each method. Consider the backup and recovery method according to the purpose of operation.

Table 5‒3: Embedded database backup and recovery methods

Backup and recovery method

Overview

Cautionary notes

Backup and recovery by using the backup enhancement function

A backup can be created while JP1/AJS3 is running.

Data can be restored up to the point that the backup was created.

After recovery, the scheduler service starts with the execution of jobnets and jobs suppressed.

The function must be set up in advance.

Job operation on the embedded database to be backed up stops during backup.

Backup and recovery by using unload log files (unload log operation)

A backup can be created while JP1/AJS3 is running.

By using unload log files, you might be able to restore data up to the point immediately before failure.

After recovery, JP1/AJS3 can start in any mode.

The function must be set up in advance.

Depending on the situation in which a failure occurred, data might be restored only up to the backup point. In this case, JP1/AJS3 must be cold-started.#

Maintenance of unload log files is required.

Backup and recovery without using the system log

JP1/AJS3 must be stopped before you create a backup.

Data can be restored up to the point that the backup was created.

JP1/AJS3 must be cold-started after recovery.

This method requires no setup.

--

Legend:

--: Not applicable

#

When JP1/AJS3 is cold-started, the registered execution-schedule information for jobnets and the execution information for jobs are initialized and can no longer be restored.

For details about the backup enhancement function, see 5.2.5 Backing up and recovering an embedded database by using the backup enhancement function. For details about the backup and recovery method that uses unload log files and the method that does not use the system log, see F. Handling database errors.

5.2.2 Target files and backup timing

Perform a backup whenever changes are made to the settings information needed to run JP1/AJS3. If performing a full backup every time is likely to be time consuming, you can back up only the information that was changed during operation or back up only the data of the embedded database. Consider also whether a full backup should be performed periodically in case a user forgets to take backup after changing a setting.

The following table lists the settings information needed for running JP1/AJS3.

Table 5‒4: Essential settings for JP1/AJS3 operation

Type of information

Settings to back up

JP1/Base settings information

See the JP1/Base User's Guide.

JP1/AJS3 - Manager settings information

Files used by JP1/AJS3

Execution agent information

Execution environment definitions for QUEUE jobs and submit jobs

Definitions of units other than root job groups

Root job group information

Calendar information for root job groups

Registered execution-schedule for root jobnets

JP1/AJS3 - Agent settings information

Files used by JP1/AJS3

JP1/AJS3 - View settings information

Environment settings files

Custom job icons

Icon image folder

Other settings information

Service account#1

Login scriopt#2

Adjustment values for kernel parameters#2

Command for collecting data for troubleshooting

Cluster support tools

User-created tools for linking to a mail system#2

#1

Windows only.

#2

UNIX only.

The settings needed to run JP1/AJS3 consist of both fixed information, such as information about the operating environment, and information that is frequently updated, such as jobnet definitions entered when configuring the system. Fixed information can be backed up whenever it is changed, but it would be unrealistic to back up information that is continually updated after every update. Consider backing up this type of information on a regular basis, such as once per day.

Typical backup plans are as follows.

Example of a backup plan at the development phase:

Back up the operating environment information, such as the environment setting parameters and files used in JP1/AJS3, when such information is changed.

Back up data in the embedded database once a week.

Back up all settings once a month.

Back up the entire system when the system configuration is changed.

Example of a backup plan when JP1/AJS3 is operational:

Back up the operating environment information, such as the environment setting parameters and files used in JP1/AJS3, when such information is changed.

Back up data in the embedded database every day.

Back up all settings once a month.

Back up the entire system when the system configuration is changed.

Supplementary note

You can back up the information about the scheduler database and agent management database by backing up the embedded database. See 5.2.1(5) Backing up and restoring an embedded database and consider the backup and recovery method.

For the backup tasks you need to perform in each program (JP1/Base, JP1/AJS3 - Manager, JP1/AJS3 - Agent, and JP1/AJS3 - View), see 2.2 Backing up the setup information for a system that uses JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide. For the necessary recovery tasks, see 2.3 Restoring the setup information for a system that uses JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

5.2.3 Taking backup while JP1/AJS3 is active

Files and folders used by JP1/AJS3 can be backed up while JP1/AJS3 is not running. Stop all JP1 products before taking backup; otherwise, if you attempt to back up the active JP1/AJS3 system, the following sorts of problems could occur:

Backed up files are inconsistent, and the restored system does not work properly.

Multiple files might be updated while a service is running. If one file is backed up after being updated, and another is backed up before being updated, inconsistencies can arise and the system will fail to work correctly after it is restored.

JP1/AJS3 cannot perform file updates.

Files are locked during backup processing. If JP1/AJS3 tries but fails to update a locked file, job execution will be affected. For this reason, we recommend that you back up JP1/AJS3 settings information only, as discussed in 5.2.1 Backup and recovery methods.

If you need to perform backup while JP1/AJS3 is running, do not back up the following files and folders:

JP1/AJS3 - Manager

Files and folders listed in the following tables in A.1 JP1/AJS3 - Manager files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting:

Table A-3 Files and folders that the user does not need to modify or reference (JP1/AJS3 - Manager for Windows)

Table A-19 Files and directories that the user does not need to modify or reference (JP1/AJS3 - Manager for UNIX)

JP1/AJS3 - Agent

Files and folders listed in the following tables in A.2 JP1/AJS3 - Agent files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting:

Table A-35 Files and folders that the user does not need to modify or reference (JP1/AJS3 - Agent for Windows)

Table A-44 Files and directories that the user does not need to modify or reference (JP1/AJS3 - Agent for UNIX)

5.2.4 Constant backup by copying and mirroring a disk

You can use the disk copy and mirroring functionality# provided by hardware to constantly back up the contents of a disk.

#

The TrueCopy function of Hitachi disk array systems is an example.

Copy the disk you want to back up as the main volume to the disk used for backup (remote volume). Because the contents of the main volume are constantly backed up, you can switch the connection to the remote volume and continue operation if the main volume can no longer be used due to a hardware failure or similar problem.

(1) Prerequisite conditions

The following are the prerequisite conditions for constant backup of a disk.

The hardware for the disk to be backed up must have the following specifications:

The order in which data is written to the main and remote volumes is guaranteed.

It must be guaranteed that the hardware ensure consistency between the main and remote volumes if data copying between shared disks stops.

Write protection of the remote volume must be guaranteed during data copying between shared disks.

The version of JP1/AJS3 - Manager must be 09-10 or later.

The JP1/AJS3 database must be a standard configuration or a standard configuration without ISAM.

A logical host environment must be used.

If JP1/AJS3 operates in a cluster system, the conditions described in 10.1.1 Prerequisites for JP1/AJS3, and the scope supported by JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide must be satisfied.

(2) Support scope

The scope of JP1/AJS3 support is the same as when JP1/AJS3 is used for disaster recovery. See 11.1.2(2) Support scope in the JP1/Automatic Job Management System 3 Administration Guide.

(3) System configuration

The following figure shows an example of a system configuration that uses constant backup of a disk.

Figure 5‒1: Example of a system configuration that uses constant backup of a disk

(4) Method of operation

Use the disk copy and mirroring functionality of the hardware to start and stop copying, and to check the status. These functions are not provided by JP1/AJS3.

Note that the disk copy and mirroring functionality of the hardware might degrade the performance of the general operation of jobs (job definition, execution, and display). Therefore, make sure that you test the operation of jobs while data is being copied before using the disk copy and mirroring functionality in live operation.

(5) Precautionary note

When switching the connection from the main volume to the remote volume, perform a disaster-recovery start of JP1/AJS3 to resume operation. For details about a disaster-recovery start, see 6.2.1 Temporarily changing the start mode of JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

5.2.5 Backing up and recovering an embedded database by using the backup enhancement function

You can back up all of the tables in a JP1/AJS3 database (embedded database) in case a failure occurs. For details about the data stored in the embedded database, see 2.6 Determining the JP1/AJS3 database configuration. If a failure occurs in the embedded database, you can use the backup data to restore the embedded database to the status when the backup data was created.

(1) Characteristics of backup and recovery by using the backup enhancement function

In an environment in which the backup enhancement function is enabled, you can back up the embedded database while JP1/AJS3 is running.

The recovery process can restore the registered execution-schedule information, the execution statuses, the execution results of jobs and jobnets, and the values of parameters that change with each job execution (macro valuables and passing information), in addition to the definitions of units, schedules, and calendars. Because there is no need to register jobnets for execution after recovery, the time required for recovery after a failure can be reduced.

After the embedded database recovers, the scheduler service that runs on the recovered embedded database automatically starts in disaster recovery mode, when you next start the scheduler services. This means that the scheduler service starts with job execution suppressed, and the statuses of jobs and jobnets are changed. If job execution is suppressed, you can use JP1/AJS3 - View or a command to check the status of each job, and then change the statuses of jobs or rerun jobs as needed. For details about the statuses of jobnets and jobs when the start mode is disaster recovery, see the description about the disaster-recovery start in 6.2.1(3) Jobnet and job statuses for each start mode in the JP1/Automatic Job Management System 3 Administration Guide.

Cautionary notes

Execution result details and temporary changes cannot be recovered.

Note that, in an environment in which the backup enhancement function is used, the amount of data to be stored in the embedded database increases compared to an environment in which the backup enhancement function is not used because information required for recovery is stored in the embedded database. For this reason, the performance of processing accompanied by update of the embedded database such as job execution and registration for execution will decline. If the system requires the JP1/AJS3's processing performance, verify the performance in an actual environment before considering the use of the backup enhancement function.

(2) Target of backup and recovery

The backup enhancement function backs up and recovers all data stored in the embedded database. Data not stored in the embedded database, such as JP1/AJS3 environment setting information, is not backed up. When using the backup enhancement function, consider how to back up data that is not stored in the embedded database, for example, by backing up the entire system or backing up individual data items as needed.

(3) Settings for using the backup enhancement function

To use the backup enhancement function, you need to enable this function when setting up the embedded database. For details about how to do this, see 21.6 Settings for backing up and recovering an embedded database while JP1/AJS3 is running in the JP1/Automatic Job Management System 3 Configuration Guide.

You can enable or disable the backup enhancement function for each embedded database. When you set up multiple scheduler services on the same embedded database, make sure that the function is enabled or disabled identically for the embedded database and all of its scheduler services.

The following figure shows a configuration that can be used to enable the backup enhancement function and a configuration that cannot be used.

Figure 5‒2:  Configuration that can be used to enable the backup enhancement function

(4) Backup and recovery by using the backup enhancement function

To back up and recover an embedded database by using the backup enhancement function, use the jajs_dbbackup and jajs_dbrestore commands. For details about how to back up and restore, see 2.5 Backing up and recovering JP1/AJS3 - Manager by using the backup enhancement function in the JP1/Automatic Job Management System 3 Administration Guide.

(5) Considerations before using the backup enhancement function

Consider the following before you use the backup enhancement function:

Job operation on the embedded database to be backed up stops during backup processing. Determine the backup intervals and when to perform backup, considering the operation status of JP1/AJS3 jobs. For the standard time required for backup, see (6) Standard time required for backup.

During backup processing, the following operations on the embedded database to be backed up and the scheduler services that run on that embedded database are suspended until backup processing ends. Therefore, determine the backup intervals and when to perform backup, considering the operation status of JP1/AJS3. For the standard time required for backup, see (6) Standard time required for backup.

Starting a scheduler service

Executing a command that operates a unit defined in the scheduler service

Performing operations on a scheduler service from JP1/AJS3 - View

Executing a command that operates the embedded database

Executing a remote jobnet defined in a scheduler service (executive host)

Executing a remote jobnet defined in a scheduler service (execution target host)

Performing operations on a scheduler service from JP1/AJS3 - Web Console

Adding, deleting, or changing an execution agent or an execution agent group#

#

If the agent management database is stored in the embedded database to be backed up.

The backup enhancement function creates a backup of an embedded database. When you operate JP1/AJS3 in a configuration containing multiple embedded databases, specify whether to create a backup for each embedded database. Then, determine the backup intervals and when to perform backup.

The disk must have sufficient free space to accommodate the embedded database to be backed up. For an estimate of the disk space required for backup, see jajs_dbbackup in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

The backup data can be recovered in an embedded database environment for which the following items match those of the environment in which the backup data was created:

The version of JP1/AJS3 - Manager

The version of the embedded database

Configuration of the embedded database

Scheduler service configuration

Added database area (Only when the database area of the embedded database was expanded by using the ajsembdbaddarea command in the environment in which the backup was created.)

The system definition of embedded database

Consider the procedure for recovering an environment in which the preceding items match that of the environment in which the backup data was created. For example, back up the entire system. For details about how to check each item, see 2.5.2(3) Obtaining information about the backup environment in the JP1/Automatic Job Management System 3 Administration Guide.

You cannot use the backup enhancement function together with unload log files for the embedded database. For details about the unload log files for the embedded database, see F.1 Overview of database backups.

If the backup enhancement function is enabled, you can no longer use the ajsembdbbackup and ajsembdbrstr commands. For details about ajsembdbbackup command, see ajsembdbbackup in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference. For details about ajsembdbrstr command, see ajsembdbrstr in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

Operation with the unregistration mode set as asynchronous is highly recommended. When JP1/AJS3 is initially installed and set up, you do not need to change the unregistration mode because it is set to asynchronous. However, if JP1/AJS3 is installed as an upgrade installation, unregistration mode might be set to synchronous. For details about the unregistration mode, see 6.1.7 Changing the mode in which unregistration or generation management deletes the generations of a jobnet in the JP1/Automatic Job Management System 3 Configuration Guide and 15.1.7 Changing the mode in which unregistration or generation management deletes the generations of a jobnet in the JP1/Automatic Job Management System 3 Configuration Guide. In an environment where the backup enhancement function is enabled, there might be more impact on cancel registration time due to the increase in information stored in the database.

If the backup enhancement function is enabled, you can no longer use the procedures described in 6.1.7(1)(b) When registration information for the jobnet that was being executed is necessary in the JP1/Automatic Job Management System 3 Configuration Guide and 15.1.7(1)(b) When registration information for the jobnet that was being executed is necessary in the JP1/Automatic Job Management System 3 Configuration Guide. Therefore, to change the unregistration mode from synchronous to asynchronous in an environment in which the backup enhancement function is enabled, you need to perform a cold start. If you want to enable the backup enhancement function, also consider operating the system by setting the unregistration mode to asynchronous.

If you enable the backup enhancement function, you will need to make a new estimate regarding resources that are used. Make an estimate regarding the following items.

Memory requirements, disk capacity, kernel parameters

For the estimates about memory requirements, disk capacity and kernel parameters, see 3.2 Estimating system performance.

Database area

For the estimate about the database area, see 3.3 Estimating the database area.

Size-of-pool-used-for-locking

For the estimate about the size of pool used for locking, see 23.1.1 Examining the embedded-database operating environment and operating method in the JP1/Automatic Job Management System 3 Configuration Guide.

If the backup enhancement function is enabled, in addition to the information stored in the existing database, the values of parameters that change with each job execution (macro valuables and passing information) are stored in the new table area (AJS2DATA2) in the database. The size of these information stored in the database varies depending on the job execution results. Therefore, consider daily monitoring the utilization of the new table area (AJS2DATA2). The usage of the table area can be checked with the ajsembdbstatus command.

For details about ajsembdbstatus command, see ajsembdbstatus in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

The utilization of the table area can be calculated by the following formula:

(Total Segment - Unused Segment) / (Total Segment) x 100

If the utilization of the table area exceeds 60%, consider the following measures.

Perform maintenance of the embedded database

If the maintenance is not performed regularly, the table area may be inefficient. For details, see 6.1.2 Considering maintenance methods.

Re-estimate and expand the database area

Re-estimate the size of the required database area and, if necessary, expand the database area with the ajsembdbaddarea command. For details about ajsembdbaddarea command, see ajsembdbaddarea in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(6) Standard time required for backup

The time required for backup by using the backup enhancement function depends on the size of the data area used by the embedded database, operation status of JP1/AJS3, and disk performance of the environment where JP1/AJS3 is installed. Therefore, when you estimate the precise time required for backup, actually create a backup. To confirm the precise time required for backup, actually create a backup and then check the backup information file that shows the time it took for backup. For details about the backup information file, see jajs_dbbackup in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

5.3 Redundancy

This section discusses redundancy in JP1/AJS3. In addition to backing up the system, duplicating part of the system is another effective way of preparing for unexpected situations. Should a failure occur, a redundant system can be restored to normal operation with less trouble. JP1/AJS3 supports software redundancy (in a cluster system) and hardware redundancy (database and network).

The following figure shows an example of a JP1/AJS3 system with a partially redundant configuration. Consider implementing redundancy as required.

Figure 5‒3: Example of a redundant JP1/AJS3 system

Software redundancy

JP1/AJS3 supports cluster systems. A cluster system consists of a number of linked servers that operate as a single system, so that work tasks can continue processing should a failure occur.

For details about cluster systems, see the documentation for your OS and cluster software. For the processing flow when JP1/AJS3 is used in a cluster configuration, see 10. Operation in a Cluster System in the JP1/Automatic Job Management System 3 Administration Guide.

Database redundancy

JP1/AJS3 uses a database to manage work task definitions and execution results. Consider implementing redundancy through the hard disk functionality. For example, you could implement database redundancy by configuring the hard disks into a RAID array.

Network redundancy

JP1/AJS3 supports multi-LAN configurations: JP1/AJS3 - Manager, JP1/AJS3 - Agent, or JP1/AJS3 - View is installed on a host that has multiple NICs, and the host is connected to multiple LANs.

The communication settings for JP1/AJS3 are based on those for JP1/Base. For details about the communication settings for JP1/Base, see the JP1/Base communication protocol and explanation of how to set up JP1/Base communication according to the network configuration in the JP1/Base User's Guide.

5.4 Countermeasures for a large-scale disaster

As countermeasures for a large-scale disaster, JP1/AJS3 supports disaster recovery that uses the disk copy and mirroring functionality# provided by the hardware.

#

The TrueCopy function of Hitachi disk array systems is an example.

5.4.1 Overview of disaster recovery

Disaster recovery refers to measures that are taken for unexpected events such as system shutdown caused by a large-scale disaster.

JP1/AJS3 supports disaster recovery that copies JP1/AJS3 data on the shared disk to a shared disk at a remote site. If the system fails because of an event such as a disaster, the JP1/AJS3 system at the remote site can continue operation by using the copied data. The disk copy and mirroring functionality of the hardware is used to copy data between shared disks.

The following figure shows the concept of disaster recovery supported by JP1/AJS3.

Figure 5‒4: Concept of disaster recovery supported by JP1/AJS3

For details about JP1/AJS3 disaster recovery operation, see 11. Disaster Recovery in JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

This subsection describes the considerations required for using JP1/AJS3 for disaster recovery.

5.4.2 Disaster recovery considerations

The following describes the considerations you must keep in mind for using JP1/AJS3 for disaster recovery.

Table 5‒5: Considerations for using JP1/AJS3 for disaster recovery

No.

What to consider

Explanation

1

The work tasks to which disaster recovery should apply

Determine the work tasks running in JP1/AJS3 that you want to resume operation on the remote site immediately after the site has stopped because of a large-scale disaster, and determine whether disaster recovery should be used.

2

The disaster recovery post-recovery processes

Determine a site on which work tasks should be resumed if the main site stops. Also determine whether to continue to run the work tasks whose operation has resumed at the remote site or return their operation to the original site.

3

The hosts, OSs, and programs to be prepared

Check the system prerequisites, and examine the computers, OSs, and programs, such as JP1/AJS3 - Manager, required for each site.

For details about the prerequisites for disaster recovery, see 11.1.2(1) Prerequisites in the JP1/Automatic Job Management System 3 Administration Guide.

4

The conditions for using the system

Check the conditions for using the system, and examine the system configuration.

For details about the disaster recovery system configuration supported by JP1/AJS3, see 11.1.3 Configuration of a disaster recovery system compatible with JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

5

The system configuration

6

Estimates for the processing performance of the system

Estimate the processing performance in a disaster recovery environment. For details, see 5.4.3 Estimating processing performance in a disaster recovery environment.

5.4.3 Estimating processing performance in a disaster recovery environment

The following describes how to estimate the processing performance in a disaster recovery environment.

(1) Estimating the processing performance for normal operation when disk copy is used

During normal operation, the contents of the shared disk are copied from the main site to the remote site. Therefore, the hardware performance and the method of copying data between disks might affect the processing performance of JP1/AJS3 at the main site.

The effects on the processing performance might also change according to the quantity of jobs and the job output processing. Therefore, execute the maximum number of jobs during the system test, and estimate the processing time.

(2) Estimating the time required for the switchover operation during disaster recovery

The following describes how to estimate the time required to resume JP1/AJS3 operation at the remote site after the main site has stopped because of a large-scale disaster.

The following figure shows the processing from stoppage of operation at the main site to the start of disaster recovery for the JP1/AJS3 service at the remote site for the resumption of operation.

Figure 5‒5: Processing steps from stoppage of main site operation until the resumption of operation at the remote site

As the time required for switching over operation in disaster recovery, estimate the time required for Disk switchover, Startup processing, and Status checking of jobnets and jobs shown in the figure. The following describes how to estimate each time.

Time required for disk switchover

Disk switchover is required to allow the remote volume to be used at the remote site. For details about this operation, see the hardware documentation. You should also estimate the processing time by switching over the disk with the maximum number of jobs running during a system test.

Time required for startup processing

When the JP1/AJS3 service is started at the remote site, the status of jobs running at the main site when the disaster occurred changes to Unknown end status, and the status of a jobnet changes to Interrupted. Recalculation of the schedule is also performed. Accordingly, the time required to start the JP1/AJS3 service is related to the number of jobs that are being executed.

You should estimate the processing time by starting the JP1/AJS3 service with the maximum number of tasks running during a system test.

Time required for checking the status of jobnets and jobs

When the JP1/AJS3 service at the remote site is started in disaster-recovery mode, the status of jobs running at the main site at the time of a disaster changes to Unknown end status, and the status of jobnets changes to Interrupted. Use the log output by JP1/AJS3 or a work application to check the status of jobnets and jobs, and the progress of work tasks.

For details about the statuses of jobnets and jobs when the start mode is disaster recovery, see the description about the disaster-recovery start in 6.2.1(3) Jobnet and job statuses for each start mode in the JP1/Automatic Job Management System 3 Administration Guide.

6 Maintenance Planning

This chapter describes maintenance of the JP1/AJS3 database.

6.1 Database reorganization

This section describes how to estimate when maintenance of the embedded database needs to be performed.

6.1.1 Flow of maintenance tasks

When JP1/AJS3 is used over an extended period with the embedded database serving as the scheduler database, invalid areas are created in the indexes as records are erased from the database. You must clean up these invalid areas by using one of the following methods:

Enable the automatic maintenance function.

Execute the ajsembdbreclaim command to make the areas usable.

Reorganize the database.

Using the automatic maintenance function or the ajsembdbreclaim command, you can reclaim and reuse pages in the database that consist only of invalid areas (unused pages). You can perform these maintenance operations even while the server is running. By performing maintenance periodically, you can enable better use of data areas.

In most circumstances, you can simply perform maintenance without having to reorganize the database. However, when page usage efficiency declines (for example, pages have only one item of valid data), the number of pages that can be reclaimed declines and it might not be possible to reuse them efficiently. The database must then be reorganized.

The following table shows the flow of maintenance tasks.

Table 6‒1: Flow of maintenance tasks

No.

Work

Relevant section

1

Estimate the maintenance time

9.1 Estimating a maintenance time in the JP1/Automatic Job Management System 3 Administration Guide

2

Select a maintenance method

6.1.2 Considering maintenance methods

3

Execute the ajsembdbreclaim command (When operation is normal)

Execute the ajsembdbreclaim command manually

9.2.2(2) Executing the ajsembdbreclaim command manually in the JP1/Automatic Job Management System 3 Administration Guide

4

Execute the ajsembdbreclaim command automatically

Use the automatic maintenance function.

9.2.1 Using the automatic maintenance function in the JP1/Automatic Job Management System 3 Administration Guide

5

Define the command as a job.

9.2.2(1) Executing the ajsembdbreclaim command automatically in the JP1/Automatic Job Management System 3 Administration Guide

6

Reorganize the database (When page reuse efficiency is low)

Use the ajsembdbrorg command to reorganize the database

9.2.3(1) Using the ajsembdbrorg command to reorganize the database in the JP1/Automatic Job Management System 3 Administration Guide

7

Use a script to reorganize the database

9.2.3(2) Using a script to reorganize the database in the JP1/Automatic Job Management System 3 Administration Guide

6.1.2 Considering maintenance methods

To maintain an embedded database, you need to enable the automatic maintenance function or execute the ajsembdbreclaim command manually or automatically.

(1) Selecting the maintenance method

The following table shows the characteristics of the automatic maintenance function and the ajsembdbreclaim command. Use the appropriate method for your operation.

Table 6‒2: Database maintenance methods

Maintenance method

Advantages

Disadvantages

The automatic maintenance function

Maintenance is automatically performed every day at the user-specified time.

After the function is set, the user does not need to perform subsequent operations.

Maintenance must be performed on a daily basis. Maintenance performed with a different frequency (for example, once every two weeks or once a month) is not possible.

Maintenance cannot be performed individually for a scheduler database or an agent management database.

Execute the ajsembdbreclaim command

The user can specify desired maintenance intervals.

Maintenance can be performed in accordance with the operation, such as performing maintenance based on the calendar or after a specific job.

Maintenance can be performed for each scheduler service or agent management database.

The user must manually perform maintenance or create a job that executes the command.

(2) Precautions on using the automatic maintenance function

If maintenance by using the automatic maintenance function and maintenance by using the ajsembdbreclaim command are performed concurrently, either maintenance processing might terminate abnormally. If you enable the automatic maintenance function, do not execute the ajsembdbreclaim command while maintenance is being performed.

(3) JP1/AJS3 - Manager configuration that does not need maintenance

When JP1/AJS3 - Manager is configured as follows, maintenance is not required because an embedded database is not used.

When the functionality of JP1/AJS3 - Manager is restricted to job execution

For details about restricting the functionality of JP1/AJS3 - Manager to job execution, see 13.1.6 Limiting JP1/AJS3 - Manager resources to those used for job operation in the JP1/Automatic Job Management System 3 Administration Guide.

When the functionality of JP1/AJS3 - Manager is restricted to the registration and operation of submit jobs

For details about restricting the functionality of JP1/AJS3 - Manager to the registration and operation of submit jobs, see 7.1.2(4) Restricting JP1/AJS3 - Manager to the registration and operation of submit jobs (Windows host).

When JP1/AJS3 - Manager is used in an external database environment

6.1.3 Estimating when to perform maintenance

You must periodically perform maintenance of an embedded database to allow invalid areas to be reused, or reorganize the database. If the automatic maintenance function is enabled, maintenance of the embedded database is automatically performed every day at the user-specified time. For maintenance performed by using the ajsembdbreclaim command, you can execute the command at any time to perform maintenance periodically.

To estimate when to execute the ajsembdbreclaim command or reorganize the database, you need to analyze the database areas. Work out how often maintenance tasks will be required, based on the analysis results described below.

When estimating when to reorganize the database, consider on which day usage of the database peaks, and by how much usage increases, on a weekly and monthly basis.

The following describes how to analyze database areas.

(1) Analyzing database areas

Execute the ajsembdbstatus command to check the database status.

If the analysis result of the ajsembdbstatus command shows that there are few unused segments and many unused pages, reorganize the database.

For details about the ajsembdbstatus command, see ajsembdbstatus in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(2) Messages indicating an area shortage

When the data storage efficiency of the embedded database declines, messages is output to the Windows event log or UNIX syslog. If the messages is output, analyze the database status by executing the ajsembdbstatus command, and reorganize the database as required. For details about the output messages, see 5.2.1 How to check the database usage in the JP1/Automatic Job Management System 3 Administration Guide.

If either of these messages is output immediately after you execute the ajsembdbreclaim command or reorganize the database, you will need to expand the indicated RD area. For details about how to expand an RD area, see ajsembdbaddarea in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

7 Special Modes of Operation

This chapter discusses what you might need to consider when using QUEUE jobs and submit jobs, or when using queueless jobs.

7.1 Considerations when using QUEUE jobs and submit jobs

The execution environment for QUEUE jobs and submit jobs consists of queues for placing registered or submitted jobs, and agents that execute jobs transferred from a queue.

When using QUEUE jobs and submit jobs, consider the following.

7.1.1 Queue/agent configuration

To execute QUEUE jobs and submit jobs in a manager/agent configuration, you must register the agent hosts that execute jobs with the manager host.

(1) Queue/agent configuration

When you register an agent host with the manager host, an internal queue (default queue) is created. The default queue has the same name as the agent host.

To execute a QUEUE job or submit job, the user specifies the queue name or agent host name, and the job is registered in that queue. Jobs are queued in order of registration and are sequentially transferred to the connected agent host.

The following figure shows an example of a queue/agent configuration.

Figure 7‒1: Example of a queue/agent configuration

To register an agent host with the manager host, use the jpqimport command or jpqagtadd command. For the command syntax, see 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

Multiple agents can be connected to a queue. By connecting multiple agents to a queue, and setting the priority of each agent and the maximum number of jobs it can execute concurrently, you can distribute the job-processing load.

The following figure shows an example of load distribution with multiple agents connected to a queue.

Figure 7‒2: Example of queue/agent load distribution

To change the maximum number of jobs that an agent host can execute concurrently, use the jpqagtalt command. To connect multiple agents to a queue and set their priorities, use the jpqagtlink command. For the syntax of each command, see 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

For a description of load distribution based on setting the maximum concurrent jobs and agent priorities, see (2) About load distribution.

(2) About load distribution

The following explains the concept of load distribution in JP1/AJS3.

We will assume the following for the examples below:

There are three agent hosts A, B, and C, each of which can execute up to three jobs at the same time (maximum number of concurrently executable jobs = 3).

All three agents are connected to queue1, allowing the processing load to be distributed.

Agent host A has the highest priority, while agent hosts B and C have the same priority.

Six submit jobs are queued for execution at the same time.

Figure 7‒3: Illustration of load distribution

The order of execution of the submit jobs (job1 to job6) is determined as follows:

Determine the execution agent for job1.

Ratio: number of active jobs / maximum number of concurrently executable jobs:

Agent host A: 0 / 3

Agent host B: 0 / 3

Agent host C: 0 / 3

The processing load is evenly distributed among all the agent hosts. Therefore, job1 is executed by agent host A, based on the order in which the agents are defined for queue1.

Determine the execution agent for job2.

The ratio (active jobs / maximum concurrent jobs) is now:

Agent host A: 1 / 3

Agent host B: 0 / 3

Agent host C: 0 / 3

Although agent hosts B and C have a lighter load, job2 is assigned to agent host A, based on the priorities of the agents defined for queue1.

Determine the execution agent for job3.

The ratio (active jobs / maximum concurrent jobs) is now:

Agent host A: 2 / 3

Agent host B: 0 / 3

Agent host C: 0 / 3

Although agent hosts B and C have a lighter load, host A executes job3, based on the priorities of the agents defined for queue1.

Determine the execution agent for job4.

The ratio (active jobs / maximum concurrent jobs) is now:

Agent host A: 3 / 3

Agent host B: 0 / 3

Agent host C: 0 / 3

Agent host A has reached its maximum number of concurrently executable jobs. Therefore, agent host B executes job4, based on the order in which the agents are defined for queue1.

Determine the execution agent for job5.

The ratio (active jobs / maximum concurrent jobs) is now:

Agent host A: 3 / 3

Agent host B: 1 / 3

Agent host C: 0 / 3

Agent host C has the lightest load. Therefore, agent host C executes job5.

Determine the execution agent for job6.

The ratio (active jobs / maximum concurrent jobs) is now:

Agent host A: 3 / 3

Agent host B: 1 / 3

Agent host C: 1 / 3

Agent hosts B and C have a lighter load than A, and their load distribution is even. Therefore, agent host B executes job6, based on the order in which the agents are defined for queue1.

(3) Running multiple execution hosts on the same computer

In JP1/AJS3, you can set the maximum number of jobs that can be executed concurrently by each of the managed agents. By defining multiple agent host names as aliases on the same computer (one IP address), and registering different kinds of jobs with each agent alias, you can distribute work tasks within one computer. For example, hostB and hostC can be defined as aliases of a real host (hostA), allowing work tasks to be distributed on one computer as in the following figure. Note that queueless jobs cannot be executed using an alias for the agent host name.

Figure 7‒4: Example of distributing work tasks

To realize this kind of configuration, add the agent host name aliases to the configuration definition of the job execution control. Also specify the agent host name aliases in the hosts file so that the IP address can be resolved from each alias. For details about adding agent host names, see (b) Configuring the job execution control for QUEUE jobs and submit jobs.

When you define agent aliases in the jp1hosts information or jp1hosts2 information of JP1/Base, JP1 can have its own hosts information without changing the hosts file or other OS settings.

(a) Defining jp1hosts information or jp1hosts2 information

For details about how to define jp1hosts information or jp1hosts2 information, see the relevant section in the JP1/Base User's Guide.

Important

When you have registered jp1hosts information or jp1hosts2 information, JP1/AJS3 no longer searches the hosts file and the DNS server for the host names and IP addresses you entered in the jp1hosts information or jp1hosts2 information. Therefore, you must define both the real host name and aliases for an IP address in the jp1hosts information or jp1hosts2 information. Place the real host name before the aliases.

(b) Configuring the job execution control for QUEUE jobs and submit jobs

To add agent aliases, follow the steps below.

For the command syntax, see 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

Add agent definitions dynamically.

To add an agent definition, execute the jpqagtadd command with the -ah option specified. In the -ah option, specify an agent host name defined as an alias in the jp1hosts information or jp1hosts2 information. In the -cp option, specify the maximum number of jobs that can be executed concurrently by the agent, bearing in mind any jobs that will place a lock on the resource.

For example, suppose hostA executes routine jobs, and you want to execute one job exclusively on hostB, which is defined as an agent alias. Set the maximum number of concurrently executable jobs as follows:

jpqagtadd [-mh manager-host-name] -ah hostA -cp 0:00-0:00=5
jpqagtadd [-mh manager-host-name] -ah hostB -cp 0:00-0:00=1

With these settings, hostA can execute a maximum of five jobs concurrently, while hostB can execute only one registered job at any one time.

Open the queue.

Because the entrance to the queue is closed when you add an agent definition, you must open the queue using the jpqqueopen command.

For example, to open the entrance to hostA's queue, execute the command as follows:

jpqqueopen [-mh manager-host-name] -ah hostA -en

(4) Notes on the execution environment required for QUEUE jobs and submit jobs

Note the following when planning the execution environment for QUEUE jobs and submit jobs.

(a) Maximum number of concurrently executable jobs (QUEUE jobs and submit jobs)

In JP1/AJS3, you can set the maximum number of jobs that an agent host can execute concurrently. When this maximum is reached, subsequent jobs are placed in the wait state. By setting a maximum number of concurrently executable jobs, you can restrict the number of jobs being executed and distribute the load during particular time periods, or among multiple agents when more than one agent host is connected to a queue.

The maximum number of concurrent jobs must be specified per execution agent. You cannot set a maximum per queue.

Notes on setting a maximum number of concurrently executable jobs

The default setting (maximum of five concurrent jobs, 24 hours a day) will suffice if only short jobs are executed, and no more than a few jobs will be registered for execution simultaneously. However, if you execute jobs with long execution times or register many jobs at the same time, the number of concurrent jobs will quickly reach the maximum, and remain there for extended periods of time. This might affect the execution of subsequent jobs.

When the maximum number of concurrently executable jobs is reached on an agent host, subsequent jobs wait in the queuing status until the active jobs finish. In such cases, jobs will take longer than expected to execute. Take the job execution time and the number of jobs executed per unit time into consideration when you set the maximum number of concurrently executable jobs.

Checking whether the maximum number of concurrent jobs has been reached when jobs remain in queuing status

When the number of active jobs on an agent host reaches the maximum number of concurrently executable jobs, subsequent jobs might remain in the queuing status for a long time before being executed. To check whether the maximum number of concurrently executable jobs has been reached, execute the jpqagtshow command and compare the number of active jobs (EXECUTING) against the maximum number of concurrently executable jobs (CUREXECHGNUM). For details about the jpqagtshow command, see jpqagtshow in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

By setting up JP1/AJS3 to output the following message to the integrated trace log when the maximum number of concurrent jobs is reached and no more jobs can be executed, you can check whether this is the reason for execution delays:

KAVU4310-I  The number of executing jobs reaches the
concurrently-executable-job-limit (maximum-number-of-concurrently-executable-jobs) at the agent (agent-host-name) (host name: host-name, job number: job-number)

For details about how to specify this setting, see 6.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

(b) Notes on the execution order of submit jobs

Submit jobs registered by the jpqjobsub command are executed in the order in which they are submitted. However, if any of the following situations applies when a job is sent to the execution agent host, it might not be executed in the proper order:

The agent usage rate at the execution agent host has reached the limit.

The execution agent host has failed or stopped.

A job that accesses the same execution-locked resource as the job being transferred has just ended.

By setting relationship lines for a job or jobnet, you can prevent the job execution order from being changed. Consider using relationship lines if the jobs executed in your system can be grouped in separate jobnets.

If jobnet operation is not feasible, enable the setting that prevents any change to the submit job execution order. This will ensure that, until the above situation is resolved, the job registered first will always be taken from the queue first, thereby preventing any change to the execution order.

For details about this setting, see 7.1.11 Setting for preventing changes in the submit job execution order.

Agent usage rate here refers to the ratio of active jobs to the maximum number of concurrent jobs at an agent host. For details about the agent usage rate, see 10.4.1(6) Distributing jobs among execution hosts (agent hosts) in the manual JP1/Automatic Job Management System 3 Overview.

Supplementary note

Jobs submitted with an execution start time specified in the -st option of the jpqjobsub command might sometimes fail to start by the specified time, depending on factors such as the availability of the agent host to which the job is to be sent. Such jobs remain in the queuing status, along with other jobs waiting for execution, until the agent host is restored. Once the agent host becomes available again, the queued jobs are transferred, but in the order they were submitted, not in order of their execution start times.

(c) Action when too many jobs are enumerated by the jpqendjobshow or jpqjobshow command

When execution of the jpqendjobshow command (enumeration of completed jobs) or jpqjobshow command (enumeration of queued jobs) produces a long list of jobs in the standard output file, the command and other requests might fail or take a long time to execute.

Consider the following to prevent such problems.

When using the jpqendjobshow command:

To reduce the amount of data, specify how many items of job information to acquire in the -rn option, or specify the time range of the acquired job information in the -sa and -sp options.

When using the jpqjobshow command:

To reduce the amount of data, specify the owner user name of the jobs to be acquired in the -u option, or specify the status of the jobs to be acquired in the -s option. If the problem still persists, change the communication timeout value. The default is 10 minutes.

For details about how to change the communication timeout value, see 6.2.14 Changing the timeout value for the job execution control manager process in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.2.14 Changing the timeout value for the job execution control manager process in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

When enumerating job information, the job execution control manager (jpqman) consumes memory in proportion to the number of listed items. With a large number of items in the list, the jpqjobshow command or jpqendjobshow command sometimes fails and message KAVU4280-E is output to the integrated trace log. If this happens, you might need to perform a setting to reduce memory usage by the job execution control manager when enumerating job information.

For details about this setting, see 7.1.12 Setting to reduce memory usage by the job execution control manager (jpqman) when enumerating job information.

7.1.2 Setup for using QUEUE jobs and submit jobs

(1) Setting the execution environment for QUEUE jobs and submit jobs

By default, the execution environment for QUEUE jobs and submit jobs is created on the local host as the execution agent. However, depending on your system requirements, you might need to change the job execution environment (by adding configuration definition information to the job execution environment).

The job execution environment needs to be changed when:

There are multiple execution hosts in the system.

JP1/AJS3 is linked with another system (JP1/NQSEXEC or JP1/OJE, for example).

Jobs are distributed to multiple execution hosts.

Particular jobs place a lock on the same resource.

If you need to change the execution environment for QUEUE jobs and submit jobs, add configuration definition information about the execution hosts (agents), queues, or execution-locked resources, using either of the following methods:

Add the information using a batch file.

Add the information dynamically while the system is running.

These two methods are described below.

(a) Changing the execution environment for QUEUE jobs and submit jobs using a batch file

The following describes how to change the execution environment for QUEUE jobs and submit jobs using the jpqimport command. Recreate the execution environment database as follows:

Copy jpqsetup.conf (execution environment configuration definition file for QUEUE jobs and submit jobs), open the copied file in an editor, and then define the queues and agents.

The following are the paths for saving the execution environment configuration definition file for QUEUE jobs and submit jobs:

In Windows

Physical host

JP1/AJS3 - Manager -installation-folder\conf\jpqsetup.conf

Logical host

shared-folder\jp1ajs2\conf\jpqsetup.conf

In UNIX

Physical host

/etc/opt/jp1ajs2/conf/jpqsetup.conf

Logical host

shared-directory/jp1ajs2/conf/jpqsetup.conf

For details about the contents to write in this file, see jpqimport in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

A coding example is shown below:

Figure 7‒5: Example of an execution environment configuration definition file for QUEUE jobs and submit jobs

Save the file you have edited.

Delete all files and temporary files from the database directory of the execution environment for QUEUE jobs and submit jobs.

Stop the JP1/AJS3 service, and then delete the files using the following commands:

In Windows:

del database-directory-for-QUEUE-and-submit-jobs\*#1

del work-directory-for-manager-process-for-QUEUE-and-submit-jobs\M_JPQ*#2

In UNIX:

rm database-directory-for-QUEUE-and-submit-jobs/*#1

rm work-directory-for-manager-process-for-QUEUE-and-submit-jobs/M_JPQ*#2

#1

The database directory of the execution environment for QUEUE jobs and submit jobs is the folder specified in the environment setting parameter DatabasePath in [{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Database]. For details about the DatabasePath environment setting parameter, see 20.5.2(3) DatabasePath in the JP1/Automatic Job Management System 3 Configuration Guide.

#2

The work directory used by the manager process in the execution environment for QUEUE jobs and submit jobs is the folder specified in the environment setting parameter WorkPath in [{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Process]. For details about the WorkPath environment setting parameter, see 20.5.2(1) WorkPath (for manager process) in the JP1/Automatic Job Management System 3 Configuration Guide.

Execute the jpqimport command.

The database is re-created, and the execution environment for QUEUE jobs and submit jobs is set up.

For the jpqimport command syntax and notes, see jpqimport in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

(b) Changing the execution environment for QUEUE jobs and submit jobs dynamically

Using commands such as jpqagtadd and jpqqueadd, you can add, delete, or change agents and queues while JP1/AJS3 is running. To add configuration definition information about the execution environment for QUEUE jobs and submit jobs dynamically, use the jpqagtadd, jpqqueadd, or jpqresadd command. To change the information dynamically, use the jpqagtalt or jpqquealt command. For the syntax of each command, see 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

To add execution hosts (agents) using the jpqagtadd command, follow these steps:

Add an agent and set the maximum number of jobs it can execute concurrently.

Make sure that the host name of the agent you are adding can be resolved to an IP address. If you do not specify the maximum number of concurrent jobs, the default is 00:00-00:00=0 (no concurrent jobs, 24 hours a day). That is, no jobs can be executed. To enable jobs to be executed by the new agent, specify 1 or higher, or change the maximum number of concurrent jobs afterwards using the jpqagtalt command. For an example of specifying the maximum number of concurrent jobs in the command's -cp option, see the notes following jpqagtalt in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

jpqagtadd -ah agent-host-name -cp maximum-number-of-concurrent-jobs

Open the entrance to the default queue.

When you create an agent, a default queue of the same name is created automatically. The entrance to the queue is closed immediately after an agent is added by the jpqagtadd command. You must therefore open the queue using the jpqqueopen command.

jpqqueopen -ah agent-host-name -en

Change the maximum number of jobs and the warning value for the default queue.

By default, the maximum number of jobs and warning value for a queue is set as 4,294,967,295. There is no need to change this value unless you need to limit the number of jobs being executed.

jpqquealt -ah agent-host-name -mj maximum-number-of-jobs -wj job-count-warning-value

Connect another agent to the queue and define its priority.

The agent you added with the jpqagtadd command is connected to the default queue. Change the settings if you want to connect another agent to this queue to share the job processing. By connecting multiple agents and specifying their priorities, you can distribute jobs among the agents according to their specified priorities.

jpqagtlink -ah agent-host-name -lh additional-agent-host-name -clp priority-of-additional-agent-host

Check the settings.

Execute the jpqagtshow and jpqqueshow commands to make sure that the settings you performed in steps 1 to 4 are correct.

jpqagtshow -ah agent-host-name

jpqqueshow -ah agent-host-name

(2) Setting up the function for automatically reorganizing ISAM files (Windows host)

You can set up JP1/AJS3 - Manager so that the data files used by the physical host and logical hosts are automatically reorganized when the JP1/AJS3 service starts. This ISAM reorganization function is disabled by default at installation time.

To enable the ISAM reorganization function, copy the file jp1ajs_spmd_pre.conf.model, located in the environment-settings file storage folder, to the file jp1ajs_spmd_pre.conf in the same folder. Set the file's access permission so that it can be read with the JP1/AJS3 service account. The environmental setting file storage folders are as follows:

Physical host

JP1/AJS3-Manager-installation-folder\conf

Logical host

shared-folder-specified-by-the-jajs_setup_cluster -command\jp1ajs2\conf

With the ISAM reorganization function enabled, when the JP1/AJS3 service starts, the batch file jpqautocond.bat in the folder JP1/AJS3-Manager-installation-folder\bin also starts. This batch file reorganizes the data files in the execution environment for QUEUE jobs and submit jobs.

The following message is output to the integrated trace log when the automatic reorganization of the ISAM files ends:

When the reorganization ends normally

KAVU5015-I

When the reorganization ends abnormally

KAVU5016-E

Cautionary note

To reorganize ISAM files, disk space equivalent to about twice the size of the largest ISAM file in the execution environment for QUEUE jobs and submit jobs must be available on the drive containing the work directory for the physical host or logical host (work directory for manager process execution, specified in the environment setting parameter WorkPath).

In addition, free space of about the same size as the largest of the ISAM files is required on the drive containing the database directory of the execution environment for QUEUE jobs and submit jobs.

Supplementary note

jpqautocond.bat executes a number of processes. It checks the validity of the ISAM files to be reorganized and ensures they can be recovered if reorganization fails (Jischk). It then extracts the data from each ISAM file to a work file (Jisext), recreates the file (Jisconv), and renames the file as the master file. If an error occurs in any of these processes, an error message is output to the reorganization log file shown below. Take corrective action, as indicated in the message.

For Windows Server 2012 or Windows Server 2008, if the installation folder is the default installation folder or is in a folder protected by the system:

Physical host:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log\jpqautocond[file-number].log

Logical host:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log\jpqautocond_[logical-host-name][file-number].log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

For Windows Server 2012 or Windows Server 2008, if the installation folder is other than the above:

Physical host:

JP1/AJS3-Manager-installation-folder\log\jpqautocond[file-number].log

Logical host:

JP1/AJS3-Manager-installation-folder\log\jpqautocond_[logical-host-name][file-number].log

file-number is a number between 1 and 4, representing the log file name.

When all four log files are full, they are reused, starting from the oldest file.

(3) Setting up the function for automatically reorganizing ISAM files (UNIX host)

You can set up JP1/AJS3 - Manager so that the data files used by the physical host and logical hosts are automatically reorganized when the JP1/AJS3 service starts. This ISAM reorganization function is disabled by default at installation time.

To enable the ISAM reorganization function, copy the file jp1ajs_spmd_pre.conf.model, located in the directory for environment settings files, to the file jp1ajs_spmd_pre.conf in the same directory. The environmental setting file storage directories are as follows:

Physical host

/etc/opt/jp1ajs2/conf

Logical host

shared--directory-specified-by-the-jajs_setup_cluster -command/jp1ajs2/conf

With the ISAM reorganization function enabled, jpqautocond in the /opt/jp1ajs2/bin directory is activated. This script reorganizes the data files in the execution environment for QUEUE jobs and submit jobs.

The following message is output to the integrated trace log when the automatic reorganization of the ISAM files ends:

When the reorganization ends normally

KAVU5015-I

When the reorganization ends abnormally

KAVU5016-E

Cautionary note

To reorganize ISAM files, disk space equivalent to about twice the size of the largest ISAM file in the execution environment for QUEUE jobs and submit jobs must be available in the partition containing the work directory for the physical host or logical host (work directory for execution of the manager process, specified in the environment setting parameter WorkPath).

In addition, free space of about the same size as the largest of the ISAM files is required in the partition containing the database directory of the execution environment for QUEUE jobs and submit jobs.

Supplementary note

The jpqautocond script executes a number of processes. It checks the validity of the ISAM files to be reorganized and ensures they can be recovered if reorganization fails (Jischk). It then extracts the data from each ISAM file to a work file (Jisext), recreates the file (Jisconv), and renames the file as the master file. If an error occurs in any of these processes, an error message is output to the reorganization log file shown below. Take corrective action, as indicated in the message.

Physical host

Error messages are output to the following log file:

/var/opt/jp1ajs2/log/schedule/jpqautocond[file-number].log

file-number is a number between 1 and 4, representing the log file name.

When all four log files are full, they are reused, starting from the oldest file.

Logical host

Error messages are output to the following log file:

/var/opt/jp1ajs2/log/schedule/jpqautocond_[logical-host-name][file-number].log

file-number is a number between 1 and 4, representing the log file name.

When all four log files are full, they are reused, starting from the oldest file.

(4) Restricting JP1/AJS3 - Manager to the registration and operation of submit jobs (Windows host)

JP1/AJS3 - Manager can be restricted solely to the registration and operation of submit jobs by job execution control commands, rather than the performance of job operations based on jobnets. To use JP1/AJS3 - Manager in this way, you must change the following JP1/AJS3 definition files:

jp1ajs_spmd.conf

jp1ajs_service_0700.conf

jp1ajs_hstd.conf

jp1ajs_hstd_0700.conf

jp1ajs_agtd.conf

To edit these definition files:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

JP1/AJS3 service

Using a text editor such as Notepad, edit the following files.

(1) Edit JP1/AJS3-installation-folder\conf\jp1ajs_spmd.conf so that it contains the following lines only:

jajs_hstd|jajs_hstd.exe|||1800|
jajs_agtd|jajs_agtd.exe|||1800|

(2) Change the following line in JP1/AJS3-installation-folder\conf\jp1ajs_service_0700.conf.

Change from:

jajs_hstd|jajs_hstd.exe||0|3|3|21600|0|0|jajs_dbmd|1|||||||

Change to:

jajs_hstd|jajs_hstd.exe||0|3|3|21600|0|0||1|||||||

(3) Edit JP1/AJS3-installation-folder\conf\jp1ajs_hstd.conf so that it contains the following lines only:

network|ajsnetwd.exe|||1800|
submitqueue|jpqman.exe|||1800|

(4) Change the following lines in JP1/AJS3-installation-folder\conf\jp1ajs_hstd_0700.conf.

Change from:

network|ajsnetwd.exe||0|3|3|21600|0|0|ajsinetd|1|||||||
submitqueue|jpqman.exe||0|3|3|21600|0|0|agentm|1|||||||

Change to:

network|ajsnetwd.exe||0|3|3|21600|0|0||1|||||||
submitqueue|jpqman.exe||0|3|3|21600|0|0|network|1|||||||

(5) Edit JP1/AJS3-installation-folder\conf\jp1ajs_agtd.conf so that it contains the following line only:

queuea|jpqmon.exe|||1800|

When writing these parameters, do not create any blank lines (or lines of spaces only).

(5) Restricting JP1/AJS3 - Manager to the registration and operation of submit jobs (UNIX host)

JP1/AJS3 - Manager can be restricted solely to the registration and operation of submit jobs by job execution control commands, rather than the performance of job operations based on jobnets. To use JP1/AJS3 - Manager in this way, you must change the following JP1/AJS3 definition files:

jp1ajs_spmd.conf

jp1ajs_service_0700.conf

jp1ajs_hstd.conf

jp1ajs_hstd_0700.conf

jp1ajs_agtd.conf

To edit these definition files:

Stop JP1/AJS3.

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop
# /opt/jp1ajs2/bin/jajs_spmd_status

Using a text editor such as vi, edit the following files.

(1) Edit /etc/opt/jp1ajs2/conf/jp1ajs_spmd.conf so that it contains the following lines only:

jajs_hstd|/opt/jp1ajs2/bin/jajs_hstd|||1800|
jajs_agtd|/opt/jp1ajs2/bin/jajs_agtd|||1800|

(2) Change the following line in /etc/opt/jp1ajs2/conf/jp1ajs_service_0700.conf.

Change from:

jajs_hstd|/opt/jp1ajs2/bin/jajs_hstd||0|3|3|21600|0|0|jajs_dbmd|1|||||||

Change to:

jajs_hstd|/opt/jp1ajs2/bin/jajs_hstd||0|3|3|21600|0|0||1|||||||

(3) Edit /etc/opt/jp1ajs2/conf/jp1ajs_hstd.conf so that it contains the following lines only:

ajsnetwd|/opt/jp1ajs2/bin/ajsnetwd|||1800|
jpqman_hst|/opt/jp1ajs2/bin/jpqman|||1800|

(4) Change the following line in /etc/opt/jp1ajs2/conf/jp1ajs_hstd_0700.conf.

Change from:

ajsnetwd|/opt/jp1ajs2/bin/ajsnetwd||1|3|3|21600|0|0|ajsinetd|1|||||||
jpqman_hst|/opt/jp1ajs2/bin/jpqman||0|3|3|21600|0|0|ajsagtmd|1|||||||

Change to:

ajsnetwd|/opt/jp1ajs2/bin/ajsnetwd||1|3|3|21600|0|0||1|||||||
jpqman_hst|/opt/jp1ajs2/bin/jpqman||0|3|3|21600|0|0|ajsnetwd|1|||||||

(5) Edit /etc/opt/jp1ajs2/conf/jp1ajs_agtd.conf so that it contains the following line only:

jpqmon|/opt/jp1ajs2/bin/jpqmon|||1800|

Restart JP1/AJS3.

When writing these parameters, do not create any blank lines (or lines of spaces only).

7.1.3 Database for QUEUE jobs and submit jobs

JP1/AJS3 uses an ISAM database as the database for QUEUE jobs and submit jobs. This database manages definition information about agents, queues, and execution-locked resources defined by the jpqimport command or by dynamic reconfiguration. It also manages job information and job statuses from registration through to completion. The following table gives details about the tables in the database for QUEUE jobs and submit jobs.

Table 7‒1: Database tables used in the execution environment for QUEUE jobs and submit jobs

Table name

Contents

Row length#

(bytes)

Variable-length rows (bytes)

Number of keys

JPQSYSINFO

System control information

28

N/A

1

JPQAGTINFO

Agent definition information

524

N/A

2

JPQSCHINFO

Scheduling information (number of concurrent jobs)

12

N/A

1

JPQQUEINFO

Queue definition info

280

N/A

2

JPQCONINFO

Queue/agent connection information

12

N/A

1

JPQRESINFO

Execution-locked resources definition information

68

N/A

2

JPQJOBINFO

Job definition information

5,860

N/A

2

JPQJOBCTRL

Job control information

656

N/A

2

JPQENVINFO

Environment variable information

516

more than 4

1

JPQTRANSINFO

Transfer file information

1,036

N/A

1

JPQNFYINFO

Status notification information (such as the client name, destination, port ID)

540

N/A

1

Legend:

N/A: Not applicable

#

The row length given for a variable-length table is the total size of fields other than the variable-length portion.

By default, the database for QUEUE jobs and submit jobs uses synchronous write mode. This mode guarantees the sequence in which data is written to the database, thereby increasing reliability. For details about setting the write mode for updating ISAM files, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary note

Do not create any direct symbolic links to the ISAM files in the database for QUEUE jobs and submit jobs. Symbolic links are destroyed when ISAM files are moved or recreated during database reorganization, resulting in new ISAM files being created in the database directory.

Because the files in the database directory are managed by the directory in which they are stored, specify the database directory if you need to create a symbolic link.

Consider the following when using QUEUE jobs and submit jobs:

Optional settings for the ISAM database

Troubleshooting the ISAM database

Maintaining the ISAM database

(1) Optional settings for the ISAM database

Set the following options as required:

Synchronous write mode

Automatic reorganization of the ISAM database

(a) Synchronous write mode

Data can be written to the ISAM database in either synchronous or asynchronous write mode. Asynchronous write mode enhances performance, but data files and key files might become inconsistent if a failover occurs. To protect data during a failover when using a cluster system, we recommend that you set synchronous write as the ISAM write mode. Synchronous write mode maintains data consistency by following the order in which the data is written by JP1/AJS3, so that inconsistencies do not arise among the database tables. However, even in synchronous write mode, files can still be corrupted by a power outage while the OS is writing to the disk.

If you are using the ISAM database and file consistency is the only issue, you can fix any inconsistencies by reorganizing the database. However, depending on the timing, it might not be possible to recover from a disk error or file error caused by a power outage, whichever write mode is set. Bearing these points in mind, consider backing up the execution environment definition for QUEUE jobs and submit jobs from time to time.

(b) Automatic reorganization of the ISAM database

The ISAM database features an automatic reorganization function. You can choose whether to automatically reorganize the database of the execution environment for QUEUE jobs and submit jobs when the JP1/AJS3 service starts. If you do not enable this function, processing performance will gradually deteriorate over time, due to the growing unavailable areas and fragmentation of variable-length tables in the database. Enable the ISAM automatic reorganization function for this reason. For the procedure, see 7.1.2(2) Setting up the function for automatically reorganizing ISAM files (Windows host) or 7.1.2(3) Setting up the function for automatically reorganizing ISAM files (UNIX host).

If you are using a cluster system, we recommend that you enable automatic reorganization of the ISAM database so that recovery can be performed when JP1/AJS3 starts. In the event of a failover (switching of work task processing from the active server to a standby server), the database will need to be reorganized to restore the data and index pages if inconsistencies arise due to the timing of the failover. However, because files are reorganized one by one, as the number of execution results kept for QUEUE jobs and submit jobs continues to grow, the database can take a long time to reorganize and JP1/AJS3 services might take longer to start. Repeated failovers are typical of a cluster system, so you must adjust the start timeout value set in the cluster software. The time required for ISAM reorganization is proportional to the actual number of records. If adjusting the cluster software's start timeout is not possible, perform settings to prevent ISAM files from becoming excessively large (for example, change the number of days that job information is kept) so as to shorten the reorganization time.

Disable automatic reorganization of the ISAM database if you want JP1/AJS3 services to start quickly at all times and you plan to reorganize the ISAM database manually.

Important

To reorganize the ISAM database, disk space equivalent to about twice the size of the largest ISAM file in the execution environment for QUEUE jobs and submit jobs must be available on the drive containing the work directory for the physical host or logical host (work directory for execution of the manager process, specified in the WorkPath environment settings parameter). In addition, free space of about the same size as the largest of the ISAM files to be reorganized is required on the drive containing the database directory of the execution environment for QUEUE jobs and submit jobs.

(2) Troubleshooting the ISAM database

The ISAM database needs to be recreated if an error occurs. For details about how to perform a status check and recreate the ISAM database, see 2.11 Troubleshooting problems related to invalid ISAM files in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(3) Maintaining the ISAM database

The following describes how to run a JP1/AJS3 system continuously over a long period using the JP1/AJS3 maintenance mode. Maintenance mode allows you to reorganize the ISAM database without interrupting active work tasks.

To perform maintenance in maintenance mode, execute the jajs_maintain command at a time when few work tasks are being executed.

An example of jajs_maintain execution is as follows:

jajs_maintain -m manager

For the command syntax, see jajs_maintain in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

See also (c) Notes on maintenance mode.

The maintenance mode provided by JP1/AJS3 temporarily disables some of the system's functionality.

Because its functionality is partially disabled, the system runs in a degenerated state, but still continues operation. If the functionality disabled by maintenance mode is accessed while the system is degenerated, the function is executed after the system is restored without resulting in an error.

The purpose and types of maintenance mode are described next.

(a) Purpose of maintenance mode

After placing JP1/AJS3 in maintenance mode, you can reorganize the ISAM database.

Suppose you are executing 10,000 jobs per day with the ISAM database, and need to perform maintenance about once a year. With twice as many jobs (20,000 per day), the reorganization frequency is doubled (once every six months). The greater the number of jobs being executed, the more often maintenance is required, with a corresponding increase in administrative time and costs.

In previous versions that did not offer a maintenance mode, you had to stop the system to reorganize the database, and start it again afterwards. Now, using the JP1/AJS3 maintenance mode, you can perform maintenance simply by placing the system temporarily in a degenerated state. Also, the jajs_maintain command can be scheduled for automatic execution by JP1/AJS3, allowing long-term system operation with maintenance performed transparently. For details about the jajs_maintain command, see jajs_maintain in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

You can also perform maintenance by gradually stopping just the manager functionality of JP1/AJS3 - Manager. In this mode, JP1/AJS3 - Manager denies requests to the manager process of the job execution control for QUEUE jobs and submit jobs, including job execution requests from other hosts and requests executed by the jpqjobsub command. Information about active jobs is not lost, however, because changes in job statuses can still be retained by the execution control agent for QUEUE jobs and submit jobs. When performing maintenance in this manner, choose a time when just a few jobs are being executed because the amount of memory used in accumulating unsent job status notifications between the manager and agent increases in proportion to the number of jobs.

Although all processes that access the database stop during maintenance, the execution control for QUEUE jobs and submit jobs starts again as soon as the reorganization is completed.

(b) Estimating how often to perform maintenance

With the database for QUEUE jobs and submit jobs, job execution performance drops by about 20% after approximately four million jobs have been executed with the JP1/AJS3 service running continuously.

If you are executing 10,000 jobs per day, you will need to reorganize the ISAM files about once a year. With twice as many jobs (20,000 per day), the reorganization frequency is doubled (once every six months). Using these figures as a guideline, monitor unused areas in the files, and estimate when maintenance will be required.

Note that periodically reorganizing the database is unnecessary in maintenance mode if you use the function for automatically reorganizing ISAM files when the JP1/AJS3 service starts.

(c) Notes on maintenance mode

Some JP1/AJS3 functions are disabled while the system is in a degenerated state in maintenance mode. When using maintenance mode, bear in mind your operating environment and determine the best time for performing maintenance.

Maintenance mode and restrictions on user operations

The following table shows the restrictions on user operations while JP1/AJS3 is in maintenance mode.

Table 7‒2: Maintenance mode and restrictions on user operations

User operation

Whether the operation can be performed

Execution of a QUEUE job from JP1/AJS3 - View#1

No

Execution of commands used at setup

Yes

Execution of commands for customizing the environment

No#1

Execution of commands for controlling JP1/AJS3

No#2

Execution of commands for operating on units

Yes

Execution of commands for executing jobs

Yes

The command that operate embedded database

Yes

The command used for the time of an error

Yes

The command used by special operation

No#3

Legend:

Yes: Can be performed.

No: Cannot be performed.

Note

The "User operation" in this table corresponds to classification of the command indicated on 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

#1

The command besides the jpqdbcond command can be used. When execute a QUEUE job during degeneration, a job will be start failure. Message KAVU0218-E is shown to the Execution result details dialogue box, which is JP1/AJS3 - View at this time.

#2

It can be used besides jajs_stop command, jajs_stop.cluster command, jajs_spmd_stop command and jajs_killall.cluster command.

#3

The commands can be used besides the command used by the QUEUE job and the submit job execution environment. When execute a QUEUE job during degeneration, a job outputs message KAVU4500-W and message KAVU0218-E in integrated trace log, and ends abnormally.

Do not attempt the operations marked No in the above table.

For details about the commands for performing user operations, see 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

Maintenance mode and restrictions on linkage with another host or system

The following table shows the restrictions on operations that link with JP1/AJS3 on another host or with another system while JP1/AJS3 is in maintenance mode.

Table 7‒3: Maintenance mode and restrictions on linkage with another host or system

Operation that links with another host or system

Whether the operation can be performed

Execution of a QUEUE job by JP1/AJS3 on another host#

No

Job execution by another system (JP1/NQSEXEC or JP1/OJE, for example)

No

Execution of a remote jobnet transferred to another host#

No

Execution of a remote jobnet transferred from another host

No

Legend:

No: Cannot be performed.

#

Do not place JP1/AJS3 in maintenance mode on the local host from the time the remote jobnet starts until it ends.

Because the remote host or system cannot recognize that the linked host is in maintenance mode, the job enters the Ended abnormally status. Make sure you choose an appropriate time to perform maintenance.

(4) Notes on the database (ISAM files) for QUEUE jobs and submit jobs

The JP1/AJS3 ISAM files might become inconsistent if the JP1/AJS3 service stops due to a system error or other problem during execution of a jobnet or job. This occurs if the contents of cache memory were not written to the disk when JP1/AJS3 stopped. If you restart the service with inconsistent ISAM files, operations on the interrupted jobnet are not guaranteed. When a system error interrupts service processing, make sure that you reorganize the ISAM files before you restart JP1/AJS3. If the database reorganization fails, recreate the ISAM files or cold-start JP1/AJS3.

The ISAM files used by JP1/AJS3 need to be reorganized during operation.

Because performance gradually deteriorates over time when using a database with variable-length tables, plan to reorganize the database when four million jobs have been executed.

In addition, monitor the JPQJOBINFO.K02 file in the database of the execution environment for QUEUE jobs and submit jobs to ensure it does not exceed 20 megabytes.

If you continue running the system past this point without reorganizing the database, performance could rapidly deteriorate.

For details about reorganizing the ISAM database, see 9.3 Reorganizing a database when QUEUE jobs and submit jobs are used in the JP1/Automatic Job Management System 3 Administration Guide.

The data files that store the tables in the ISAM database used by JP1/AJS3 cannot exceed 2 gigabytes in size.

The size of the ISAM data files depends on how many records are stored in the tables at peak times.

Some tables tend to become particularly large during job processing. You can control the size of these files as recommended below.

Note that various problems could occur when the file size increases to nearly 2 gigabytes. Performance is likely to decline due to the increase in disk I/O operations, and there might not be enough desk space to reorganize the files. Consider reducing the number of records to keep files as small as possible.

JPQJOBINFO table in the database of the execution environment for QUEUE jobs and submit jobs

For standard configurations, less than 200,000 records can be stored.

The total number of records in the JPQJOBINFO table is the number of jobs processed during the number of days set for retaining job execution information. If you set a short retention period, files are less likely to get too large.

7.1.4 Estimating the size of the logs output by the execution environment for QUEUE jobs and submit jobs

There is no real need to estimate the size of the log files output in the execution environment for QUEUE jobs and submit jobs unless the number of jobs executed per days exceeds 10,000. If the number of jobs is less than this number, you can use the default. If more than 10,000 jobs are executed every day, we recommend that you estimate the size of the logs.

Determine both the size and number of log files for each type of log. Then define the values you have estimated using the jajs_config command.

For the environment setting parameter for submitting jobs in 3.4.5 Estimating the size of the logs output by execution, execute the following command, and then restart JP1/AJS3:

jajs_config -k definition-key-name "environment setting parameter-name-1"=definition-contents-1
["environment setting parameter-name-2"=definition-contents-2]

Only one definition key can be specified in definition-key-name. If you want to set environment setting parameter different in a definition keys, you must execute the jajs_config command for each definition key.

7.1.5 Environment settings for executing QUEUE jobs and submit jobs

The environment settings (environment setting parameters) for executing QUEUE jobs and submit jobs are set in the job execution environment settings file (AJS3_Queue.conf).

For details about the environment setting parameters, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

For the setting procedure, see 4.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 14.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

7.1.6 Setting the assumed JP1 user function

In JP1/AJS3, the user name JP1 user is used for managing access privileges. Each OS user (a user who executes jobs) is mapped to specific JP1 users. This means that execution requests from hosts other than those defined in the user mapping will be denied.

Under JP1/AJS3's user management scheme, each OS user must be individually mapped to one or more JP1 users. If non-specific OS users will be using JP1/AJS3, each OS user will need to be mapped to a JP1 user, increasing the administrator's workload.

To lessen the task of user mapping, JP1/AJS3 provides a assumed JP1 user function that maps OS users to a single default JP1 user, allowing unmapped OS users to operate JP1/AJS3 with the access privileges of the default JP1 user. (But if an OS user executing a job is registered as a JP1 user, the privileges of that JP1 user still apply.) The assumed JP1 user function can be used when executing commands available in an execution environment for JP1/AJS3 QUEUE jobs and submit jobs. For details about these commands, see 1.5.10(1) Commands available in an execution environment for queue or submit jobs in the manual JP1/Automatic Job Management System 3 Command Reference.

The following describes how to set up the assumed JP1 user function, and provides cautions on usage.

(1) Setting procedure (Windows)

Set user information in JP1/Base.

For details about how to set user information, see 3.1.1(1) Setting user information in the JP1/Automatic Job Management System 3 Configuration Guide.

Execute the jpqregguestuser command.

Set the JP1 user registered in step 1 as the default JP1 user.

For the command syntax, see jpqregguestuser in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Restart JP1/AJS3.

The definition takes effect.

This completes setup of the assumed JP1 user function.

The jpqregguestuser command is also used when clearing the assumed JP1 user function setting.

(2) Setting procedure (UNIX)

Stop JP1/AJS3.

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1
# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Set user information in JP1/Base.

For details about how to set user information, see 13.1.1(1) Setting user information in the JP1/Automatic Job Management System 3 Configuration Guide.

Execute the jpqregguestuser command.

Set the JP1 user registered in step 2 as the default JP1 user.

For the command syntax, see jpqregguestuser in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Restart JP1/AJS3.

The definition takes effect.

This completes setup of the assumed JP1 user function.

The jpqregguestuser command is also used when clearing the assumed JP1 user function setting.

(3) Notes

Only one default JP1 user can be set per JP1/AJS3 - Manager host.

For the JP1 user defined as the default JP1 user, set user mapping and the JP1 permission level in the same manner as for ordinary JP1 users.

When setting the JP1 permission level, make sure that:

The permission level allows all potential operations.

The operating environment cannot be corrupted by user errors.

In a cluster system, execute the jpqregguestuser command on both the active and standby hosts.

For the jpqregguestuser command syntax, see jpqregguestuser in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

7.1.7 Method of determining the agent host to which a job is distributed

When a QUEUE job or submit job is to be distributed to execution agents, if the priority and usage rate of these agents are the same, the load on the agents can be balanced by selecting the agent with the longest idle time.

To set the method for determining which agent host to distribute QUEUE jobs and submit jobs to, follow the procedure below.

There is no need to perform this setting for queueless jobs.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒4: Environment setting parameter for setting the method of determining the agent host for distributed jobs

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Agent]#

"LeastRecentlyUsed"=

Method of determining the distribution-destination agent host

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(35) LeastRecentlyUsed in the JP1/Automatic Job Management System 3 Configuration Guide.

7.1.8 Option for deleting job information asynchronously

In JP1/AJS3, jobs that have been kept for longer than the set retention period are deleted from the ISAM database used for job execution. Deletion is performed when JP1/AJS3 starts, or at the base time for deleting job information. The data file update mode is normally set as synchronous. In synchronous mode, although updates take longer due to the frequent disk I/O operations, the data is more reliable because the buffer contents in memory are written to the disk every time JP1/AJS3 finishes a write process. Executing jobs in parallel with JP1/AJS3 write processing might affect job execution performance. If job information is kept one day or longer, set the base time for deleting job information at a time when just a few jobs are being executed.

If you cannot predict when just a few jobs will be executed, set the option below to quickly delete job information asynchronously. When job information is deleted asynchronously, buffer contents are written to the disk using the OS buffering. Because this write process is not synchronized with JP1/AJS3 processing, there are fewer disk I/O operations and less effect on job performance when deletion processing is performed in parallel with job execution. With a RAID system, however, the gain in performance might not be great. Also, with asynchronous deletion, inconsistencies can easily arise between the information managed in memory and the information written to disk. The lower reliability therefore makes this option unsuitable for cluster configurations. Before using this option, carefully consider the environment in which it will be used.

This option for deleting job information asynchronously is valid only when the data file update mode is set as synchronous.

The procedure for setting this option is as follows.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒5: Environment setting parameter for setting the option for deleting job information asynchronously

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Database]#

"DeleteFlashOption"=

Option for deleting job information asynchronously

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(7) DeleteFlashOption in the JP1/Automatic Job Management System 3 Configuration Guide.

7.1.9 Setting the retention period for job information

When 0 is set as the number of days to retain job information, job information is deleted 10 minutes after a job ends. If the job execution command is used to execute jobs, or if the job execution result is not checked at termination even for jobs executed from a jobnet, setting the retention period to 0 days ensures that job information about completed jobs is always deleted, which helps to keep the amount of stored information from increasing too much. Thus, at the base time for deleting job information, large numbers of jobs do not have to be deleted all at once. The 0 setting is also effective in environments where it is difficult to estimate a good base time for deleting job information, such as in a system that executes jobs round the clock or in an irregular pattern. For jobs executed from a jobnet, however, the status reporting process checks the job status at termination. If status reporting fails due to a communication error, the status reporting process monitors the status of the job at 5-minute polling intervals. Any job information deleted during this interval cannot be referenced, and the job is assumed to have ended abnormally.

You can handle such errors by setting the option below to change the length of time that job information is kept after a job ends. This setting is valid only when the retention period for job information is set to 0 days.

The following describes the procedure for setting how long to keep job information after a job ends when the retention period for job information is set to 0 days.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒6: Environment setting parameter for setting the retention period for job information

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Database]#

"PreserveMinute"=

Retention period for job information

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(8) PreserveMinute in the JP1/Automatic Job Management System 3 Configuration Guide.

7.1.10 Setting for disabling deletion of job information when JP1/AJS3 starts

Job information deletion processing is executed either at the base time for deleting job information, which is specified in the environment settings, or when the JP1/AJS3 service starts. When a base time is used, job information is deleted if it has been kept longer than the set number of days at the base time. When deletion is timed with JP1/AJS3 service startup, job information is deleted if it has been kept longer than the set number of days at the start time. If a failover occur in a cluster configuration while a large number of jobs are being executed, or if the JP1/AJS3 service is restarted due to a system error or other issue, job execution performance might decline due to the conflict with job deletion processing.

By using either of the following options to disable the deletion of job information when the JP1/AJS3 service starts, you can avoid conflict between deletion processing and job execution:

Delete expired job information when JP1/AJS3 starts, using the base time as the reference point

When you use this option, job information that has been kept longer than the set number of days at any point between the base time and start time is not deleted when the JP1/AJS3 service starts. However, if the JP1/AJS3 service was stopped at the previous base time and deletion processing was not performed, expired job information might still remain in the database. Only this expired job information will be deleted the next time JP1/AJS3 starts.

By electing to delete expired job information at the base time without stopping the JP1/AJS3 service, you can prevent job information from being deleted when the JP1/AJS3 service starts.

Disable deletion of job information when JP1/AJS3 starts

This option disables deletion of job information when the JP1/AJS3 service starts.

When you resume JP1/AJS3 operation after a long period of inactivity, there might be a large amount of expired job information to be deleted. In this case, the successive I/O requests generated by the deletion process on ISAM files when the JP1/AJS3 service starts could slow the execution of jobs immediately after service startup.

With this option set, job information is deleted only at the base time, not at service startup. This prevents adverse effects on the execution performance of jobs executed immediately after the JP1/AJS3 service starts. Do not use this option, however, if your system is set up to stop the JP1/AJS3 service at the base time for deleting job information.

If you use this option with the JP1/AJS3 service set to stop at the base time for deleting job information, expired job information will accumulate over time, and the job execution environment database will occupy more and more space on the disk. An increase in the disk space occupied by the job execution environment database can have various effects, including preventing the JP1/AJS3 service from starting and jobs from being executed, and can even affect programs other than JP1/AJS3.

The following describes how to disable deletion of job information at JP1/AJS3 service startup when the retention period for job information is set as one day or longer.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒7: Environment setting parameter for disabling deletion of job information when the JP1/AJS3 service starts

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Database]#

"StartUpDelete"=

Setting to disable the deletion of job information at JP1/AJS3 service startup

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(9) StartUpDelete in the JP1/Automatic Job Management System 3 Configuration Guide.

(3) Setting for disabling deletion of job information when JP1/AJS3 starts and its effects

The following table shows the relationship between the disabling deletion of job information when JP1/AJS3 starts, and whether deletion processing is performed.

Table 7‒8: Relationship between the setting for disabling deletion of job information when JP1/AJS3 starts, and whether deletion processing is performed

Setting for disabling deletion of job information at JP1/AJS3 startup

Deletion of job information at JP1/AJS3 startup

Time for deleting job information

0

Yes#

Base time

1

Yes

Start time of JP1/AJS3 service

2

No

--

Legend:

Yes: Deletion processing is performed.

No: Deletion processing is not performed.

--: Not applicable.

#

Job information is not deleted when the JP1/AJS3 service starts if deletion took place at the preceding base time.

7.1.11 Setting for preventing changes in the submit job execution order

The following describes the setup for preventing any change in the execution order of submit jobs.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒9: Environment setting parameter for preventing changes in the submit job execution order

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Job]#

"PreventChangeJobOrder"=

Setting to prevent changes in the submit job execution order

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(22) PreventChangeJobOrder in the JP1/Automatic Job Management System 3 Configuration Guide.

7.1.12 Setting to reduce memory usage by the job execution control manager (jpqman) when enumerating job information

When the job execution manager (jpqman) enumerates job information, memory usage is proportional to the number of listed items. With more items added, the following commands sometimes fail and message KAVU4280-E is output to the integrated trace log. If this happens, you might need to perform a setting to reduce the amount of memory used by the job execution control manager when enumerating job information.

jpqjobshow command

jpqendjobshow command

The procedure for reducing memory usage by the job execution control manager when enumerating job information is as follows.

(1) Setting procedure

Stop JP1/AJS3.

In Windows:

From Administration Tools in the Windows Control Panel, choose Services and stop the following service:

- JP1/AJS3 service

In UNIX:

Execute the following commands to stop the JP1/AJS3 processes and to check that all processes have stopped:

# /etc/opt/jp1ajs2/jajs_stop#1

# /opt/jp1ajs2/bin/jajs_spmd_status

#1

First check whether the JP1/AJS3 processes are set to stop automatically.

Execute the following command to set the environment setting parameter described in (2) below.

jajs_config -k definition-key-name "environment setting parameter-name"=definition-contents

Restart JP1/AJS3.

The setting takes effect.

(2) Environment setting parameter

Table 7‒10: Environment setting parameter for reducing memory usage by the job execution control manager (jpqman) when enumerating job information

Definition key

Environment setting parameter

Definition contents

[{JP1_DEFAULT|logical-host-name}\JP1NBQMANAGER\Job]#

"EnumJobSaveMemory"=

Setting to reduce memory usage by the job execution control manager when enumerating job information

#

In the portion {JP1_DEFAULT|logical-host-name}, specify JP1_DEFAULT for the physical host, or logical-host-name for a logical host.

For details about what is defined in this environment setting parameter, see 20.5.2(23) EnumJobSaveMemory in the JP1/Automatic Job Management System 3 Configuration Guide.

7.2 Considerations when using queueless jobs

When using queueless jobs, consider the following:

The size of the output log files

The environment settings for executing queueless jobs

7.2.1 Estimating log file sizes

Estimate the size of the JP1/AJS3 log files for queueless jobs. When an error occurs, this log file information is used to investigate what operation or process caused the error. If the required information has not been kept, identifying the cause will take longer. Estimate the size of the log files as exactly as you can, according to how and what sort of job processing your system performs.

When using queueless jobs, estimate the size of the following log files:

Queueless log file

Queueless trace log file

Internal execution log file for queueless jobs

(1) Estimating the size of the queueless log file

A queueless log file contains log entries output by the queueless jobs executed by an agent. Queueless log files are used primarily to monitor the execution of work tasks.

The disk space required for a queueless log file depends on how many queueless jobs are executed by the agent. Estimate the appropriate log file size and change the default disk space if necessary. For details on the default disk space and maximum disk area used by queueless log files, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Use the following formula to estimate the size of a queueless log file:

Size of a queueless log file (in bytes) = (60 + length-of-manager-host-name + length-of-scheduler-service-name + length-of-job's-full-name + length-of-agent-host-name) x 2 x number-of-jobs-to-save

For details about increasing the size of the queueless log file, see 3.5.1 Extending trace log files in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 13.4.4 Extending trace log files in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(2) Estimating the size of the queueless trace log file

A queueless trace log contains traces output by queueless jobs and by commands related to the queueless job execution control. Queueless trace logs are used primarily to investigate the cause of a problem or to calculate how long a process took.

In the initial state, the queueless trace log file is set as follows.

Path:

In Windows:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log\tracelog.ql

In UNIX:

/var/opt/jp1ajs2/log/tracelog.ql

Size:

Large enough for the traces output by approximately 10,000 jobs (specifically, 15 megabytes (15,360 kilobytes)).

Estimate an appropriate size for the trace log file and increase its size as needed. However, when you use only the queueless job manager function, you do not need to estimate the file size.

Use the following formula to estimate the size of a queueless trace log file:

Size of a queueless trace log file (in kilobyte) = 3,072 x (number-of-jobs-executed-from-the-time-a-problem-occurs-until-data-can-be-collected / 2,000)

Example: Store one day's worth of queueless trace log entries.

If 12,000 jobs are executed per day

Size of the queueless trace log file = 3,072 x (12,000 / 2,000) = 18,432 kilobytes

For details about increasing the size of the queueless trace log file, see 3.5.1(2) Extending the queueless trace log file in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 13.4.4(2) Extending the queueless trace log file in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

(3) Estimating the size of the internal execution logs for queueless jobs

The internal execution log files for queueless jobs contain traces output by queueless jobs.

In the initial state, the internal execution log files for queueless jobs are set as follows.

Path

In Windows:

JP1/AJS3-installation-folder\log\ajsqlexeclog#1
JP1/AJS3-installation-folder\log\ajsqlexeclog_ftpd#2

In UNIX:

/var/opt/jp1ajs2/log/ajsqlexeclog#3
/var/opt/jp1ajs2/log/ajsqlexeclog_ftpd#2

#1

In a cluster configuration, the file name is:

  JP1/AJS3-installation-folder\log\ajsqlexeclog-[logical-host-name]

logical-host-name is truncated after the 30th byte if the file name exceeds 255 bytes.

#2

Created in JP1/AJS3 - Manager only.

#3

In a cluster configuration, the file name is:

  /var/opt/jp1ajs2/log/ajsqlexeclog-[logical-host-name]

logical-host-name is truncated after the 30th byte if the file name exceeds 255 bytes.

Size

For the ajsqlexeclog file:

Large enough for the internal log output by the queueless agent service for approximately 40,000 jobs (specifically, 24 megabytes (24,576 kilobytes)).

For the ajsqlexeclog_ftpd file:

Large enough for the internal log output by the queueless file transfer service for approximately 20,000 jobs that involve file transfer (specifically, 10 megabytes (10,240 kilobytes)).

The size of an internal execution log for queueless job varies greatly depending on the number of queueless jobs executed, whether file transfer is involved, and other factors. Estimate an appropriate size for the internal log files and increase their size as needed.

Use the following formulae to estimate the size of the internal execution log files for queueless jobs:

Size of the ajsqlexeclog file (in kilobyte) = (number-of-queueless-jobs-executed-over-two-days x 600) / 1,024

Size of the ajsqlexeclog_ftpd file (in kilobyte) = (number-of-queueless-jobs-involving-file-transfer-executed-over-two-days x 500) / 1,024

Example: Store internal execution log files for queueless jobs when:

10,000 queueless jobs are executed per day.

3,000 of those jobs involve the transmission of transfer files or result files.

Size of the ajsqlexeclog file (in kilobyte) =

((10,000 x 2) x 600) / 1,024 = 11,719 kilobytes

Size of the ajsqlexeclog_ftpd file (in kilobytes) =

((3,000 x 2) x 500) / 1,024 = 2,929 kilobytes

For details about increasing the size of the internal execution logs for queueless jobs, see ajsqlexecsetsz in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

7.2.2 Environment settings for executing queueless jobs

The following describes the environment settings for executing queueless jobs.

Use the jajs_config command to change the values of environment setting parameters.

For details about the environment setting parameters for an execution environment for queueless jobs, see 20.10 Setting up the queueless job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Also consider the following issues.

When queueless jobs are executed in an environment where the manager host and the agent host use different character encodings

If the manager host and the agent host use different character encodings, you must specify the language code in the AJSQL_CHARCODE environment setting parameter.

This environment setting parameter is used for the character encoding conversion shown in the following figure.

Figure 7‒6: Character encoding conversion for queueless jobs

(1) Scheduler service and queueless agent service

The value of the AJSCHARCODE environment setting parameter specified for the scheduler service is used as the character encoding. Character encodings are not converted for the scheduler service.#

(2) Queueless agent service

The following data is converted to the character encoding specified for the AJSQL_CHARCODE environment setting parameter.

- Data accepted from the scheduler service

- Transfer file data

The following data is converted to the character encoding specified for the AJSCHARCODE environment setting parameter of the scheduler service that issued the request:

- Reply data to the scheduler service

- Result file data

The default value of AJSQL_CHARCODE is none. If none is set, character encodings are not converted.

If the manager and the agent use different character encodings, you must specify AJSQL_CHARCODE for the queueless agent service to which the request is sent.

(3) Queueless agent service and queueless file transfer service

The data in the transfer file is sent from the queueless file transfer service to the queueless agent service where it is converted to the character encoding used by the queueless agent service. The data in the result file is converted to the character encoding used by the queueless agent service, and is then sent to the queueless file transfer service. Character encodings are not converted in the queueless file transfer service#.

#

If UTF-8 is specified for the QLMANCHARCODE environment setting parameter for the manager, character encodings are converted.

When queueless jobs are executed on the manager host in a UTF-8 environment

To use the manager in a UTF-8 environment to execute a queueless job on an agent host that does not support UTF-8, you must specify UTF-8 for the QLMANCHARCODE environment setting parameter.

This environment setting parameter can be set only when the character encoding (value of the AJSCHARCODE environment setting parameter) of the manager is UTF-8. Do not set this environment setting parameter if UTF-8 is not the character encoding of the manager.

The following shows the scope of the QLMANCHARCODE environment setting parameter.

Figure 7‒7: Scope of the QLMANCHARCODE environment setting parameter

(1) Scheduler service

If UTF-8 is specified for both the AJSCHARCODE and QLMANCHARCODE environment setting parameters, character encodings are converted. The conversion applies to the job definition items.

The AJSCHARCODE setting is specified for each scheduler service whereas the QLMANCHARCODE setting is specified for a machine. To use queueless jobs, make sure that the AJSCHARCODE setting is the same for all the scheduler services.

(2) Queueless file transfer service

If UTF-8 is specified for the QLMANCHARCODE environment setting parameter, character encodings are converted. The conversion applies to the transfer file and result file (execution result details).

For details about the language types that you can use in the system, see 2.4.2 Language type and character encoding of the system.

8 Migration from a Previous Version

This chapter describes how to upgrade from JP1/AJS3 or JP1/AJS2, and provides notes on upgrading.

8.1 Version compatibility

To use JP1/AJS3, you must consider the compatibility among the versions of the following: each JP1/AJS3 product, JP1/Base (which is a prerequisite product for JP1/AJS3), and optional products.

The following subsections discuss the version compatibility issues shown above.

8.1.1 Version compatibility between JP1/Base and JP1/AJS3

The following table shows version compatibility between JP1/Base and JP1/AJS3.

Table 8‒1: Version compatibility between JP1/Base and JP1/AJS3

JP1/AJS3

08-50 or earlier

09-00

10-00

10-10

10-50

11-00

11-10

11-50

12-00

12-10

12-50

12-60

JP1/Base

08-50 or earlier

#1

--

--

--

--

--

--

--

--

--

--

--

09-00

--

F

--

--

--

--

--

--

--

--

--

--

10-00

--

--

F

F#2

F

--

--

--

--

--

--

--

10-10

--

--

F

F

F

--

--

--

--

--

--

--

10-50

--

--

F

F

F

--

--

--

--

--

--

--

11-00

--

--

--

--

--

F

F#3

F#3

--

--

--

--

11-10

--

--

--

--

--

F

F

F

--

--

--

--

11-50

--

--

--

--

--

F

F

F

--

--

--

--

12-00

--

--

--

--

--

--

--

--

F

F

F

F

12-10

--

--

--

--

--

--

--

--

F

F

F

F

12-50

--

--

--

--

--

--

--

--

F

F

F

F

Legend:

F: Fully compatible.

--: Not supported.

#1

See the description about version compatibility between JP1/Base and JP1/AJS2 in the JP1/Automatic Job Management System 2 Planning and Administration Guide.

#2

Linux is not supported.

To upgrade JP1/AJS3 to 10-10 when you are using Linux, you must first upgrade JP1/Base to 10-10 or later.

#3

HP-UX, AIX, and Linux are not supported.

To upgrade JP1/AJS3 when you are using HP-UX, AIX, or Linux, you must first upgrade JP1/Base to 11-10 or later.

8.1.2 Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - View

The following table shows version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - View.

Table 8‒2: Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - View

JP1/AJS3 - Manager

08-50 or earlier

09-00

10-00

10-10

10-50

11-00

11-10

11-50

12-00

12-10

12-50

12-60

JP1/AJS3 - View

08-50 or earlier

#1

#1

#1

#1

#1

--

--

--

--

--

--

--

09-00

#1

F

P

P

P

P

P

P

P#2

P#2

P#2

P#2

10-00

#1

P

F

P

P

P

P

P

P

P

P

P

10-10

#1

P

P

F

P

P

P

P

P

P

P

P

10-50

#1

P

P

P

F

P

P

P

P

P

P

P

11-00

--

P

P

P

P

F

P

P

P

P

P

P

11-10

--

P

P

P

P

P

F

F

P

P

P

P

12-00

--

P

P

P

P

P

P

P

F

P

P

P

12-10

--

P

P

P

P

P

P

P

P

F

P

P

12-50

--

P

P

P

P

P

P

P

P

P

F

F

Legend:

F: Fully compatible.

P: Partially compatible. Only the functions supported in older versions are available.

--: Not supported.

#1

For details, see the manual for the relevant version of JP1/AJS2 or JP1/AJS3.

#2

This is not supported when an external database is used as the database for JP1/AJS3 - Manager.

Cautionary note when there are different versions of JP1/AJS3 - Manager and JP1/AJS3 - View

When different versions of JP1/AJS3 - Manager and JP1/AJS3 - View are present, only the functions that are supported in the older version are available.

If unsupported detail definitions or schedule definitions exist when an older version of JP1/AJS3 - View is connected to a newer version of JP1/AJS3 - Manager, the Define Details or Schedule Settings dialog box might not be displayable. Even if the dialog boxes are displayable, the values of definition items might be set to their defaults or disabled. For this reason, if you perform setup using a newer version of JP1/AJS3 - View and then use an older version of JP1/AJS3 - View to connect to JP1/AJS3 - Manager, the defined items might be either restored to their defaults or disabled.

If you want to use the new JP1/AJS3 - Manager functions, use the same new versions of JP1/AJS3 - Manager and JP1/AJS3 - View. Note, however, that the functions in version 11-50 of JP1/AJS3 - Manager are supported in version 11-10 of JP1/AJS3 - View.

8.1.3 Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent

The following table shows version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

Table 8‒3: Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent

JP1/AJS3 - Manager

08-50 or earlier

09-00

10-00

10-10

10-50

11-00

11-10

11-50

12-00

12-10

12-50

12-60

JP1/AJS3 - Agent

08-50 or earlier#1

#2

#2

#2

#2

#2

--

--

--

--

--

--

--

09-00#1

#2

F

P

P

P

P

P

P

P

P

P

P

10-00#1

#2

P

F

F

P

P

P

P

P

P

P

P

10-10#1

#2

P

F

F

P

P

P

P

P

P

P

P

10-50#1

#2

P

P

P

F

P

P

P

P

P

P

P

11-00#1

--

P

P

P

P

F

P

P

P

P

P

P

11-10#1

--

P

P

P

P

P

F

F

P

P

P

P

11-50

--

P

P

P

P

P

F

F

P

P

P

P

12-00

--

P

P

P

P

P

P

P

F

P

P

P

12-10

--

P

P

P

P

P

P

P

P

F

P

P

12-50

--

P

P

P

P

P

P

P

P

P

F

P

12-60

--

P

P

P

P

P

P

P

P

P

P

F

Legend:

F: Fully compatible.

P: Partially compatible. Only the functions supported in older versions are available.

--: Not supported.

#1

JP1/AJS3 - Agent Minimal Edition is not supported.

#2

For details, see the manual for the relevant version of JP1/AJS2 or JP1/AJS3.

8.1.4 Version compatibility between JP1/AJS3 - Manager on different hosts

The following table shows version compatibility between JP1/AJS3 - Manager on different hosts when you execute a remote command or remote jobnet from JP1/AJS3 - Manager on the local host to JP1/AJS3 - Manager on another host.

Table 8‒4: Version compatibility between JP1/AJS3 - Manager on different hosts

JP1/AJS3 - Manager

(Executing host#1 / definition source host#2)

08-50 or earlier

09-00

10-00

10-10

10-50

11-00

11-10

11-50

12-00

12-10

12-50

12-60

JP1/AJS3 - Manager

(Execution host#3)

08-50 or earlier

#4

#4

#4

#4

#4

--

--

--

--

--

--

--

09-00

#4

F

P

P

P

P

P

P

P

P

P

P

10-00

#4

P

F

P

P

P

P

P

P

P

P

P

10-10

#4

P

P

F

P

P

P

P

P

P

P

P

10-50

#4

P

P

P

F

P

P

P

P

P

P

P

11-00

--

P

P

P

P

F

P

P

P

P

P

P

11-10

--

P

P

P

P

P

F

P

P

P

P

P

11-50

--

P

P

P

P

P

P

F

P

P

P

P

12-00

--

P

P

P

P

P

P

P

F

P

P

P

12-10

--

P

P

P

P

P

P

P

P

F

P

P

12-50

--

P

P

P

P

P

P

P

P

P

F

P

12-60

--

P

P

P

P

P

P

P

P

P

P

F

Legend:

F: Fully compatible.

P: Partially compatible. Only the functions supported in older versions are available.

--: Not supported.

#1

Host from which the command is executed.

#2

Host on which the remote jobnet is defined.

#3

Host from which the command is executed, or host on which the remote jobnet is executed.

#4

For details, see the manual for the relevant version of JP1/AJS2 or JP1/AJS3.

Different versions of JP1/AJS3 - Manager on the executing host and definition source host

When a unit in a remote jobnet uses functionality that is not supported by the version of JP1/AJS3 - Manager on the executing host, the remote jobnet ends abnormally and error message KAVS0650-E is output to the Execution Result Details dialog box. If this message appears, modify the unit definition, and then re-execute the remote jobnet.

8.1.5 Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Web Console

The following table shows versions of JP1/AJS3 - Web Console that can be connected to JP1/AJS3 - Manager.

Table 8‒5: Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Web Console

JP1/AJS3 - Manager

10-50 or earlier

11-00

11-10

11-50

12-00

12-10

12-50

12-60

JP1/AJS3 - Web Console

11-00

--

F

F

F

F

F

F

F

11-10

--

F

F

F

F

F

F

F

11-50

--

F

F

F

F

F

F

F

12-00

--

F

F

F

F

F

F

F

12-10

--

F

F

F

F

F

F

F

12-50

--

P

P

P

P

P

F

F

12-60

--

P

P

P

P

P

F

F

Legend:

F: Full functions supported by JP1/AJS3 - Web Console can be used.

P: Partially functions supported by JP1/AJS3 - Web Console can be used.

--: Not supported.

8.2 Migration to a UTF-8 environment

This section describes how to migrate to a UTF-8 environment in the following case:

Migrating Linux JP1/AJS2 - Manager from an EUC environment to a UTF-8 environment

Note that the maximum number of characters that can be used in definition items in a UTF-8 environment is less than that of the information defined in Japanese locales that are not UTF-8. This section also explains the maximum number of characters that can be used in definition items in a UTF-8 environment.

8.2.1 Migrating the character encoding in Linux from an EUC environment to a UTF-8 environment

The following describes how to migrate the encoding environment for Linux JP1/AJS2 - Manager from EUC to UTF-8.

(1) Migrating the character encoding in Linux to a UTF-8 environment

Because an overwrite installation of the product cannot be performed, you need to back up the existing definition information, uninstall the product, and then install and set up version 09-00 or later of the product.

The following shows the migration procedure.

Figure 8‒1: Migration procedure from an EUC environment to a UTF-8 environment

The following describes each step.

(2) Backing up the definition information

Back up the following definition information:

Job execution environment definition

Unit definition

(a) Backing up the job execution environment definition

To back up the job execution environment definition:

Execute the following command to output the job execution environment definition.

# jpqexport -dt isam -co file-name [-mh logical-host-name]

The job execution environment definition is output to the file specified in file-name.

Cautionary note

For centralized management, we recommend that you use jpqsetup.conf as the file to be set by the jpqimport command.

To back up the definition of a logical host, specify the logical host name in the -mh option.

Copy the contents of the output file to jpqsetup.conf.

Copy the contents of the file you output in step 1 to jpqsetup.conf.

(b) Backing up the unit definition

The following describes how to back up the jobnet settings and calendar information.

Cautionary notes

The jobnet settings and calendar information must be backed up for each scheduler service. Accordingly, back up the information for each scheduler service separately.

A user with superuser privileges for the OS must perform the following procedure.

Backing up the definition information for units other than the root job group.

Execute the following command to back up the definition information for the units in the scheduler service. The definition information includes the base time, comments, and all other definitions for each unit, but does not include information about the root job group (/), such as the base time, base day, and base month. To back up the root job group information, use the procedures in step 2 and step 3 below.

# ajsprint -F scheduler-service-name -a '/*' > unitbackup.txt

Cautionary note

When you back up a jobnet that was created by copying the root jobnet for which schedule rules have been defined to a nested jobnet, specify no for the AJSPRINTNETSCHPRF environment setting parameter.

This setting is specified by default in a new installation of JP1/AJS version 08-00 or later. If you upgrade a version of JP1/AJS earlier than 08-00 and this setting has not been specified yet, you will need to change the environment setting parameter. For details about how to change the parameter, see 4.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows) or 14.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX). For details about the environment setting parameter, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Backing up the information about the root job group.

Record the following information about the root job group:

Comments

Owners

JP1 resource groups

Base time

Base day

Base month

Backing up the calendar information for the root job group.

Execute the following command to back up the calendar information (open days and close days) for the root job group.

# ajsprint -F scheduler-service-name -d / > rootcal.txt

Cautionary note

If no calendar information is output to rootcal.txt, recovery is not needed.

(3) Installing and setting up JP1/AJS3 09-00 or later

Install and set up JP1/Base and JP1/AJS3 - Manager in a UTF-8 environment. For details about how to set up JP1/Base, see the JP1/Base User's Guide. For details about how to set up JP1/AJS3 - Manager, see 13.1 Required setup for JP1/AJS3 - Manager in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary notes

Set up the products in accordance with the environment setting parameters used in the previous version. If the settings of the new and previous versions are different, recovery might fail.

For JP1/AJS 08-00 or a later version, the environment setting parameter settings used after a new installation and new setup are different from those of JP1/AJS2 07-50 or earlier. If you want to use the same settings that were used in JP1/AJS2 07-50 or earlier, change the values of the environment setting parameters.

(4) Converting the language of backed-up definitions

Use the iconv command or a similar means to convert the backed-up definition files to UTF-8 encoding. If you have registered jobnets for fixed execution by using a schedule information file, also convert the schedule information file to UTF-8 encoding. For details about how to convert the character encoding, including how to use the iconv command, see the OS documentation.

(5) Recovering the definition information

Recover the following definition information you backed up:

Execution environment definition for QUEUE jobs and submit jobs

Unit definition

(a) Recovering an execution environment definition for QUEUE jobs and submit jobs

Use the backed-up configuration definition file (jpqsetup.conf) for the execution environment for QUEUE jobs and submit jobs to create the execution environment for QUEUE jobs and submit jobs.

To recover the execution environment definition for QUEUE jobs and submit jobs:

Delete the files in the folder containing the queue information database.

(a) For a physical host

# rm /var/opt/jp1ajs2/database/queue/*

(b) For a logical host

# rm shared-folder/jp1ajs2/database/queue/*

Execute the following command to create an execution environment for QUEUE jobs and submit jobs.

# jpqimport -dt isam -ci jpqsetup.conf [-mh logical-host-name]

To recover a logical host definition, specify the logical host name in the -mh option.

(b) Recovering the unit definition

The following describes how to recover the jobnet settings and calendar information.

Cautionary notes

The jobnet settings and calendar information are recovered for each scheduler service. Accordingly, recover the setup information for each scheduler service separately.

A user with superuser privileges for the OS must perform the procedure described below.

Make sure that JP1/AJS2 - Manager is running.

Starting the JP1/AJS2 - Manager.

In a physical host environment, execute the startup command to start JP1/AJS2 - Manager. In a logical host environment, register JP1 in the cluster software and then start JP1/AJS2 - Manager.

Recovering the definition information for units other than the root job group.

Execute the following command to recover the definition information for the units in the scheduler service. The definition information includes the base time, comments, and all other definitions for each unit, but does not include information about the root job group (/), such as the base time, base day, and base month. To recover the root job group information, use the procedures in step 3 and step 4 below.

# ajsdefine -F scheduler-service-name unitbackup.txt

Recovering the information about the root job group.

Set the following information about the root job group that you have recorded.

Comments

Owners

JP1 resource groups

Base time

Base day

Base month

Recovering the calendar information for the root job group.

Execute the following command to recover the calendar information (open days and close days) for the root job group.

# ajscalendar -F scheduler-service-name -df rootcal.txt /

Cautionary note

This command recovers the calendar of the scheduler service (AJSROOT1) itself.

If no calendar information has been output to rootcal.txt, recovery is not needed. For details, see (2) Backing up the definition information.

8.2.2 Maximum number of characters that can be defined for items when converting the character encoding to a UTF-8 environment

In a UTF-8 environment, multi-byte characters such as Japanese are represented by using more bytes than are used in Japanese locales that are not UTF-8. By default, the maximum number of bytes that can be specified for each item of a unit does not depend on the character encoding. Therefore, the maximum number of characters that can be used for definitions in the UTF-8 environment is less than the information defined in Japanese locales that are not UTF-8.

You can set up the embedded database to permit the same number of characters used in a Shift-JIS environment to be used in the UTF-8 environment for the specification of definition items such as a unit name. This setting is available for the following combinations of OSs and JP1/AJS3 - Manager versions:

Linux and JP1/AJS3 - Manager 09-50-01 or later

OS Solaris 11 and JP1/AJS3 - Manager 10-00-03 or later

AIX or HP-UX, and JP1/AJS3 - Manager 10-50-01 or later

For details, see 15.1.10 Setting for changing the number of characters specifiable for a unit name in a UTF-8 environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Cautionary notes

If you set up the embedded database to use the same number of characters that are used in a Shift-JIS environment to specify definition items such as unit names, the maximum number of nesting levels is 10. Therefore, a unit consisting of ten or more levels cannot be migrated to a UTF-8 environment. If you want to migrate such units, you need to change the unit configuration beforehand.

Migration to a UTF-8 encoding environment must be performed in the standard configuration. For an environment upgraded from JP1/AJS2 - Manager, perform the migration after changing the configuration to the standard configuration.

For details about how to change the configuration to the standard configuration, see 8.5 Upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager.

8.3 Migration of definition information from JP1/AJS2 to JP1/AJS3 on a different host

This section describes how to migrate setup information from a JP1/AJS2 host to a host on which JP1/AJS3 has been installed as a new installation.

8.3.1 How to migrate definition information when changing hosts during an upgrade

To perform a migration, back up the JP1/AJS2 setup information and then restore the information on the installed JP1/AJS3.

You can migrate setup information after setting up JP1/AJS3 on the destination host. In addition, you need to make sure that the source and destination hosts are on the same platform and have the same language environment. When you migrate information to a different platform, first set up the destination host, and then restore only the job execution environment and calendar definition information.

Note that if the host name changes, you will need to change the host name after migration.

(1) Backup on a JP1/AJS2 host

For details about how to back up setup information on a JP1/AJS2 host, see the description of backup in the JP1/AJS2 system in the JP1/Automatic Job Management System 2 Planning and Administration Guide.

(2) Restoring the setup information on a JP1/AJS3 host

For details about how to restore setup information on a JP1/AJS3 host, see 2.3 Restoring the setup information for a system that uses JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

When you perform migration from JP1/AJS2 - Manager to JP1/AJS3 - Manager, if necessary, also perform the procedure described in (3) Migration of execution agent information (JP1/AJS3 - Manager only).

(3) Migration of execution agent information (JP1/AJS3 - Manager only)

When you operate the database on the destination JP1/AJS3 in the standard configuration, you can use the procedure below to migrate the execution environment definitions for QUEUE jobs and submit jobs as execution agent information. Thus, the execution agent name in the unit definition that are also migrated can be used without any changes.

To perform the migration:

Check the JP1_HOSTNAME environment variable.

To migrate the execution environment definitions for QUEUE jobs and submit jobs from a logical host, specify the logical host name in the JP1_HOSTNAME environment variable.

To migrate the execution environment definitions for QUEUE jobs and submit jobs from a physical host, do not change the JP1_HOSTNAME environment variable.

Export the execution environment definitions for QUEUE jobs and submit jobs.

Execute the following command to export the execution environment definitions for QUEUE jobs and submit jobs to a file:

jpqexport -dt isam -co output-destination-file-name -agmfmt

Example: When the output destination file name is AgentBack.csv:

jpqexport -dt isam -co AgentBack.csv -agmfmt

After executing the command, check the return value of the command.

Cautionary notes

For the output destination file, specify a new (nonexistent) file. If you execute the command with an existing file specified, nothing will be exported.

The jpqexport command does not output anything to the standard output or standard error output. Check the return value of the command to determine whether the command terminated normally or abnormally. If the return value is 0, the command terminated normally.

The logical host from which the definitions are to be output can be specified in the -mh option of the jpqexport command. In this procedure, however, specify the logical host name in the JP1_HOSTNAME environment variable as described in step 1, rather than in the -mh option.

You can use the -agmfmt option of the jpqexport command only in this procedure. Do not use this option to back up or restore the execution environment definitions for QUEUE jobs and submit jobs.

You can use the jpqimport and jpqexport commands even in a standard configuration without ISAM. However, you will not be able to execute QUEUE jobs or submit jobs even if you import, to the migration-destination instance of JP1/AJS3, the result file exported by using the jpqexport command or the result file exported by using the -agmfmt option of the jpqexport.

Check the number of definitions to be migrated.

Execution agents or execution agent groups exceeding the maximum number of definitions cannot be migrated in the agent information.

If the result file you exported in step 2 contains agent information that exceeds the maximum number of definitions, delete unnecessary definition lines from the result file so that the number of definitions is within the maximum.

The maximum number of definitions in the agent information is as shown below.

Maximum number of execution environment definitions for QUEUE jobs and submit jobs

Agents: 1,024

Queues: 8,192

Maximum number of definitions in the agent information for JP1/AJS3 version 9

Execution agents: 1,023

Execution agent groups: 1,024

To check the number of definitions in the agent information:

(1) Use a text editor to open the output results in step 2.

Using a text editor, open the file specified in the -co option in step 2.

(2) Check the number of definitions to be migrated as execution agents.

Count the lines that begin with "A", which indicate lines that define execution agents. However, do not count a line beginning with "A","@SYSTEM", which indicates a line that defines the default execution agent.

If there are 1,024 or more lines to be processed, not all of the agent definitions can be migrated as execution agents, in which case, delete unnecessary agent definitions.

(3) Check the number of definitions to be migrated as execution agent groups

Count the lines that begin with "G", which indicate lines that define execution agent groups. If there are 1,025 or more lines to be processed, not all of the queue definitions can be migrated as execution agent groups, in which case, delete unnecessary queue definitions.

For example, if the following information is output as a result of step 2, two agent definitions will be migrated as execution agents and two queue definitions will be migrated as execution agent groups.

 "A","@SYSTEM","Agent1","00:00-00:00=5","Ef",""
 "A","Agent1","Agent1","00:00-00:00=5","Ef",""
 "A","Agent2","Agent2","00:00-00:00=0","In",""
 "G","Agent2","Agent1:16,Agent2:16","In",""
 "G","que1",,"Ef",""

Start the JP1/AJS3 service.

If the JP1/AJS3 service is already running, you do not need to restart it.

Import the information for the database for QUEUE jobs and submit jobs you exported in step 2 to the agent management database.

Execute the ajsagtadd command to import the execution environment definitions for QUEUE jobs and submit jobs to the agent management database.

For details about the ajsagtadd command, see ajsagtadd in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

Example: When the import source file name is AgentBack.csv:

ajsagtadd -f AgentBack.csv

(4) Note on migration of only a unit definition

To migrate only a unit definition from a version 8 or earlier JP1/AJS2 environment to a JP1/AJS3 environment on another host, the agent name specified as the target host in the unit definition must be defined as an execution agent#1.

If the unit definition to be migrated contains jobs that will be executed on the local host, perform either of the following operations:

Specify the default execution agent#2 as the execution agent in the unit definition containing jobs that will be executed on the local host.

You can use either of the following methods to specify the default execution agent:

- Specify @SYSTEM for the execution agent in the unit definition.

- Omit the execution agent specification in the unit definition.

In addition to the default execution agent, register an execution agent#1 that has the same name as the local host name.

#1

Use the ajsagtadd command to define the execution agent. For details about the ajsagtadd command, see ajsagtadd in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

#2

For details about the default execution agent, see 5.1.4 Default execution agent in the manual JP1/Automatic Job Management System 3 Overview.

(5) Note on the maximum number of concurrently executable jobs

When you perform a migration to JP1/AJS3 version 9 by using the procedure in (3) Migration of execution agent information (JP1/AJS3 - Manager only), two execution agents are created in the local host agent definition: the default execution agent and an execution agent that has the same name as the local host name.#

#

If the agent definition that has the same name as the local host name does not exist in version 8 or earlier, only the default execution agent is created. The execution agent that has the same name as the local host name is not created.

Care is required because the selected execution agent depends on how the execution agent is specified in the unit definition as described below.

When the execution agent is not specified in the unit definition

The default execution agent is used to execute a job.

When the local host name is explicitly specified for the execution agent in the unit definition

The execution agent that has the same name as the local host name is used to execute a job.

In addition, the maximum number of concurrently executable jobs specified for the execution agent applies to each execution agent. If the default execution agent and the execution agent with the local host name are defined, the sum of the maximum number of concurrently executable jobs specified for these agents applies to the jobs that will be executed on the local host.

For example, if local host name host1 defined as an agent in version 8 or earlier is migrated to JP1/AJS3 version 9, two execution agents, @SYSTEM and host1, are defined. If the maximum number of concurrently executable jobs for host1 is set to 00:00-00:00=10 (maximum of 10 concurrent jobs, 24 hours a day), a maximum of 15 jobs can be executed concurrently. This is because the maximum number of concurrently executable jobs for the default execution agent is 00:00-00:00=5 (maximum of five concurrent jobs, 24 hours a day).

(6) Migration of execution registration status of jobnets (JP1/AJS3 - Manager only)

If JP1/AJS2 - Manager 08-50 or later is on the source host, you can use the functions for exporting and importing execution registration information for jobnets to migrate the execution registration status of jobnets to JP1/AJS3 - Manager on the destination host. However, the execution results of jobnets and jobs cannot be migrated.

For details about how to export and import execution registration information for jobnets, see 3.4 Backing up and recovering the execution registration status of jobnets by using the ajsrgexport and ajsrgimport commands in the JP1/Automatic Job Management System 3 Administration Guide.

If the version of JP1/AJS2 - Manager on the source host is 08-10 or earlier, execution registration information for jobnets cannot be exported. In this case, you need to register the jobnets again with JP1/AJS3 - Manager on the destination host.

(7) When the migration source host name and the migration destination host name are different

For details about the procedure when the migration source host name and the migration destination host name are different, see 7.9 Changing the JP1/AJS3 host settings in the JP1/Automatic Job Management System 3 Administration Guide.

8.4 Note on programs that use code functions

JP1/AJS3 does not support the use of code functions.

If you want to create programs that use code functions, use a JP1 environment whose version is 7i or earlier. Note that programs created in an environment whose version is 7i or earlier can only operate JP1/AJS - Manager 08-00 or a later version running on an OS supported by version 7i or earlier JP1 products. In other OSs, since these programs cannot be executed, consider operation that uses JP1 Version 9 or later commands.

Also note that programs created in an environment whose version is 7i or earlier cannot use the new functions supported by JP1 Version 8 or later. If any of these new functions is contained in a job or jobnet (including upper-level jobnets), the programs are also unable to use existing functions for the job or jobnet (including upper-level jobnets). Programs that attempt to use such functions might operate incorrectly.

8.5 Upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager

This section describes how to upgrade JP1/AJS2 - Manager (JP1 Version 8 or earlier) to JP1/AJS3 - Manager (JP1 Version 9 or later).

8.5.1 Overview of the tasks for upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager

If you are using JP1/AJS2 - Manager and want to upgrade it to JP1/AJS3 - Manager 12-00 or later, you cannot perform the upgrade at once. First, upgrade JP1/AJS2 - Manager to JP1/AJS3 - Manager whose version is 09-00 to 11-50, and then change the database configuration from the compatible ISAM configuration to the standard configuration. After that, upgrade the version of JP1/AJS3 - Manager to 12-00 or later.

If you are upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager for HP-UX, Linux, or AIX, note that support for the compatible ISAM configuration was discontinued from version 11-10. In this case, first upgrade JP1/AJS2 - Manager to JP1/AJS3 - Manager whose version is 09-00 to 11-00, and then change the database configuration to the standard configuration.

For details about how to change the database configuration, see 8.5.2 How to set up JP1/AJS3 - Manager after upgrading from JP1/AJS2 - Manager.

Cautionary notes

Before you start upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager, check the OSs supported by JP1/AJS3 - Manager. If the OS of the host on which JP1/AJS2 - Manager is installed is not supported by JP1/AJS3 - Manager, you cannot upgrade JP1/AJS2 - Manager on that host. If you cannot perform the upgrade directly on the host, prepare a manager host on which the desired version of JP1/AJS3 - Manager is installed, and then migrate the definition information from JP1/AJS2 - Manager to JP1/AJS3 - Manager.

JP1/AJS3 - Manager requires more disk space and memory than JP1/AJS2 - Manager. Therefore, before performing the upgrade and migrating data, you must re-estimate the amount of disk space and memory that JP1/AJS3 - Manager will require.

You cannot begin using JP1/AJS3 - Manager until you have finished migrating the data. Depending on the amount of data and so on, data migration could take some time. Perform the upgrade and migration tasks in a planned fashion.

8.5.2 How to set up JP1/AJS3 - Manager after upgrading from JP1/AJS2 - Manager

Migration tasks must be performed first on the physical host, and then on the logical host.

(1) Estimates when migrating data

Because data migration involves the creation of temporary files, disk space equivalent to the area used by the existing scheduler services is required. After performing the migration, make sure there are no issues with the new JP1/AJS3 - Manager before you delete these temporary files. For the directory in which the temporary files are created, see jajs_migrate in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

You must also estimate the requirements of the new host environment in advance. For details about making estimates, see 3.2 Estimating system performance.

(2) Standard data migration procedure

The following figure shows the standard workflow when migrating data.

Figure 8‒2: Data migration workflow (standard)

To migrate data using the standard procedure:

Cautionary note

The logical host environment cannot shift in this procedure. the shift procedure of logical host environment, see (3) Data migration procedure when using advanced settings and 2.2.3 Installing a JP1/AJS3 series program in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 12.2.2 Notes on installation in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

Stop the JP1/AJS3 service.

In the case of the UNIX environment, please execute the ajsshmdel command after a service stop. The path of the ajsshmdel command is /opt/jp1ajs2/bin/ajsshmdel. The example of execution is shown below.

In the case of sh

/opt/jp1ajs2/bin/ajsshmdel >/dev/null 2>&1

In the case of csh

/opt/jp1ajs2/bin/ajsshmdel >&/dev/null

In UNIX, if you execute the jajs_migrate command without executing the ajsshmdel command after the service stops, the KAVS0549-E message is output and the command terminates abnormally.

Execute the jajs_migrate command.

If an embedded database is used for the scheduler database before migration, activate the embedded database, and then execute the jajs_migrate command.

An execution example is as follows:

jajs_migrate -convert -u 5

For the command syntax, see jajs_migrate in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Cautionary notes

- In the case of the UNIX version, when it uses an embedded database in the scheduler database before shift, a setup of an environment variable is required. For details, see jajs_migrate in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

- When the jajs_migrate command ends normally, check if a warning message has been output. If a warning message has been output, take the action indicated in the message.

Restart the JP1/AJS3 service.

(3) Data migration procedure when using advanced settings

The following figure shows the data migration workflow when using advanced settings.

Figure 8‒3: Data migration workflow (advanced settings)

To migrate data with advanced settings:

Stop the JP1/AJS3 service.

In the case of the UNIX environment, please execute the ajsshmdel command after a service stop. The path of the ajsshmdel command is /opt/jp1ajs2/bin/ajsshmdel. The example of execution is shown below.

In the case of sh

/opt/jp1ajs2/bin/ajsshmdel >/dev/null 2>&1

In the case of csh

/opt/jp1ajs2/bin/ajsshmdel >&/dev/null

In UNIX, if you execute the jajs_migrate command without executing the ajsshmdel command after the service stops, the KAVS0549-E message is output and the command terminates abnormally.

Execute the ajscnvdbexport command to save the database information.

An execution example is as follows:

ajscnvdbexport -F AJSROOT1 -b D:\workdir

This command operates on the pre-migration embedded database. If the embedded database is used for the scheduler database before migration, activate the embedded database and set the following environment variable before you execute the ajscnvdbexport command:

In HP-UX:

SHLIB_PATH=installation-directory-of-pre-migration-embedded-database/client/lib

In Solaris or Linux:

LD_LIBRARY_PATH=installation-directory-of-pre-migration-embedded-database/client/lib

In AIX:

LIBPATH=installation-directory-of-pre-migration-embedded-database/client/lib

For the syntax of the ajscnvdbexport command, see ajscnvdbexport in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Execute the ajsembdbinstl command to install the JP1/AJS3 database.

An execution example is as follows:

ajsembdbinstl -s "C:\Program Files\HITACHI\JP1AJS2\tools\AJS3DB" -id _JF0

For the command syntax, see ajsembdbinstl in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Cautionary note

To install an embedded database on the logical host, specify a value that is _JF1 or greater for the -id option of the ajsembdbinstl command.

Execute the ajsembdbbuild command to build the database environment.

An execution example is as follows:

ajsembdbbuild -s -d "D:\database\RDArea_JF0,D:\database\SYSArea_JF0" -p 22220 -i "C:\Program Files\HITACHI\JP1AJS2\embdb\_JF0" -id _JF0

For the command syntax, see ajsembdbbuild in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Cautionary note

In the case of the UNIX version, build the first database environment on the relevant host (-i option specification value of the ajsembdbbuild command) built on an applicable host to /opt/jp1ajs2/embdb/_JF0.

Execute the ajsembdbsetup command to set up the database environment.

An execution example is as follows:

ajsembdbsetup -F AJSROOT1 -p 22220 -id _JF0 -ru s -convert

For the command syntax, see ajsembdbsetup in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Execute the ajscnvdbimport command to migrate the database information.

An execution example is as follows:

ajscnvdbimport -F AJSROOT1 -b D:\workdir

For the command syntax, see ajscnvdbimport in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Execute the jajs_migrate command.

An execution example is as follows:

jajs_migrate -convert -S

For the command syntax, see jajs_migrate in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Cautionary note

When using JP1/AJS3 - Manager in a cluster configuration, execute the jajs_migrate command for each logical host.

Restart the JP1/AJS3 service.

(4) The notice which is at the time of re-execution of the jajs_migrate command

When re-executing the jajs_migrate command, attention is needed about the next.

A DBBKUP directory is created in the database directory of each scheduler service. When the file is stored in the directory, arrange the contents of the DBBKUP directory to a database directory.

To the ajsembdbstatus command, specify -s ust, check the state of the embedded database, which was being used by the version 8, and, in the case of a STOP state, change the database into an ONLINE state by using the ajsembdbstart command.

If the KAVS0550-E message (the following message) is output to the standard error output and the jajs_migrate command terminates abnormally, delete the directories or files below, and then re-execute the jajs_migrate command: An error occurred in the shift processing of JP1/AJS3 to the standardized configuration: jpoman_convert_to_multi 8

In Windows:

JP1/AJS2-Manager-installation-folder\log\EV_Convert_Log.log

JP1/AJS2-Manager-installation-folder\tmp\EVaction_backup

shared-folder-name\jp1ajs2\log\EV_Convert_Log.log

shared-folder-name\jp1ajs2\tmp\EVaction_backup

In UNIX:

/var/opt/jp1ajs2/log/EV_Convert_Log.log

/var/opt/jp1ajs2/tmp/EVaction_backup

shared-disk-name/jp1ajs2/log/EV_Convert_Log.log

shared-disk-name/jp1ajs2/tmp/EVaction_backup

(5) The procedure to delete environment before a shift

It you use an embedded database or HiRDB as a database of scheduler service before shift, it is necessary to delete if needed after the completion of shift. Uninstall a database according to the procedure of the manual of each version.

In addition, in the case of UNIX, execute the following command after ajsembdbunset command execution.

/opt/HiRDB_J/bin/pdesetup -u embedded database practical directory

(6) Database before a shift and after a shift

When JP1/AJS3 - Manager is a standard configuration, the database of scheduler service is stored in an embedded database.

Before shift, as a database of scheduler service of JP1/AJS2 - Manager ISAM, HiRDB, or an embedded database built by JP1/AJS2 - manager version 7 is being used, if it shifts to the database of scheduler service of JP1/AJS3 - Manager, jajs_migrate command stores the data of four scheduler services to one embedded database automatically.

When the embedded database built by JP1/AJS2 - Manager is being used before shift, if it shifts to the database of scheduler service of JP1/AJS3 - Manager, the state where it is stored as a database of two or more scheduler services to one embedded database.

To change the embedded database in which the database of the scheduler service is stored after shift, perform the procedure of (3) Data migration procedure when using advanced settings, or specify -u option to jajs_migrate command to shift.

The example of composition of the database before shift and after shift is shown below.

(Example 1) When operating with single scheduler service before shift.

Before migration

After migration

Scheduler service name

Database type

Scheduler service name

Setup identifier

AJSROOT1

ISAM

AJSROOT1

_JF0

(Example 2) When operating with two or more scheduler services before shift.

Before migration

After migration

Scheduler service name

Database type

Scheduler service name

Setup identifier

AJSROOT1

ISAM

AJSROOT1

_JF0

AJSROOT2

ISAM

AJSROOT2

AJSROOT3

ISAM

AJSROOT3

AJSROOT4

ISAM

AJSROOT4

AJSROOT5

ISAM

AJSROOT5

_JF1

AJSROOT6

ISAM

AJSROOT6

AJSROOT7

ISAM

AJSROOT7

(Example 3) When operating with two or more scheduler services before shift (ISAM, HiRDB, embedded database (Version 7) mixture environment).

Before migration

After migration

Scheduler service name

Database type

Scheduler service name

Setup identifier

AJSROOT1

ISAM

AJSROOT1

_JF0

AJSROOT2

HiRDB

AJSROOT2

AJSROOT3

HiRDB

AJSROOT3

AJSROOT4

Embedded database (Version 7)

AJSROOT4

AJSROOT5

Embedded database (Version 7)

AJSROOT5

_JF1

AJSROOT6

ISAM

AJSROOT6

AJSROOT7

ISAM

AJSROOT7

(Example 4) When operating with two or more scheduler services before shift (ISAM, embedded database (Version 8) mixture environment).

Before migration

After migration

Scheduler service name

Database type

Scheduler service name

Setup identifier

AJSROOT1

ISAM

AJSROOT1

_JF1

AJSROOT2

Embedded database (Version 8) _JAA

AJSROOT2

_JF0

(Example 5) When operating with two or more scheduler services before shift (ISAM, HiRDB, embedded database (Version 7), embedded database (Version 8) mixture environment).

Before migration

After migration

Scheduler service name

Database type

Scheduler service name

Setup identifier

AJSROOT1

ISAM

AJSROOT1

_JF2

AJSROOT2

Embedded database (Version 8) _JA0

AJSROOT2

_JF0

AJSROOT3

HiRDB

AJSROOT3

_JF2

AJSROOT4

Embedded database (Version 8) _JA0

AJSROOT4

_JF0

AJSROOT5

Embedded database (Version 7)

AJSROOT5

_JF2

AJSROOT6

Embedded database (Version 8) _JA1

AJSROOT6

_JF1

AJSROOT7

ISAM

AJSROOT7

_JF2

AJSROOT8

Embedded database (Version 7)

AJSROOT8

_JF3

AJSROOT9

Embedded database (Version 8) _JA1

AJSROOT9

_JF1

AJSROOTA

ISAM

AJSROOTA

_JF3

(7) Estimating the disk space requirements after migration from a version 8 embedded database

After migration from a version 8 embedded database, the disk space requirements depend on the migration method as described below.

(a) Standard migration

The following disk space is required for migration:

(50 + (490 + a)) x ↑ b/c ↑ + d (units: megabytes)

a: Variable that depends on the scale specified in the -s option of the jajs_migrate command

Substitute one of the following values according to the scale of the database:

l: 20,700

m: 4,200

s: 520 (default value)

b: Number of scheduler services

c: Value specified in the -u option of the jajs_migrate command (default is 4)

d: Database size for all scheduler services before migration

For ISAM: Total size of the ISAM files

For an embedded database: Variable that depends on the scale specified in the ajsembdbbuild command

Substitute one of the following values according to the scale of the database:

-l: 1,600 (default value)

-m: 800

-s: 300

If the database area has been expanded, add the amount of the increase to the value.

For HiRDB: The size created by using the HiRDB simple setup script

ajshirdbsetupl: 288

ajshirdbsetupm: 72

ajshirdbsetups: 18

ajshirdbsetupsfm1: 288

If the database area has been expanded, add the amount of the increase to the value.

Note that the space specified by the value that replaces d occupies the disk that contains the directory specified in the -T option of the jajs_migrate command. When the migration is complete, delete this information because it is no longer necessary.

(b) Migration with advanced setup

For a migration that uses advanced setup, before executing the ajsembdbbuild command, you need to determine the scale based on the database capacity and operational requirements before migration.

For the capacity required for setting up one embedded database environment, see 23.4 Advanced setup of an embedded database in the JP1/Automatic Job Management System 3 Configuration Guide.

8.6 About the system block

When you change the database configuration to a standard configuration after upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager, the following operations are suppressed on physical and logical hosts while the standard configuration is being set up. This state is called a system block.

JP1/AJS3 service startup

Execution of JP1/AJS3 commands

This section describes the events that trigger a system block and describes how to release the system block state.

8.6.1 When system blocks occur

Performing the following upgrading and setup causes the physical host and all logical hosts on JP1/AJS3 - Manager to be placed in a system block:

When JP1/AJS2 - Manager uses an ISAM database as a scheduler database, and the jajs_migrate command is used to perform data migration JP1/AJS3 - Manager in a standard configuration after an upgrade to JP1/AJS3 - Manager.

When JP1/AJS2 - Manager uses a scheduler database that is not an ISAM database, and an upgrade installation of JP1/AJS3- Manager is performed.

8.6.2 When system blocks are released

The hosts are released from a system block when the data migration performed by the jajs_migrate command has been completed.

8.7 Environment settings when upgrading to a new version

This section describes environment settings (environment setting parameter) you need to consider when upgrading to a newer version.

8.7.1 Defaults of the environment setting parameters between versions 10-50 or earlier and versions 11-00 or later

In JP1/AJS3 version 11-00, some of the defaults of the environment setting parameters have been changed.

The following describes the differences between versions 10-50 or earlier and versions 11-00 or later.

Versions 10-50 or earlier

Some of the defaults of the environment setting parameters are not their recommended values. You need to change the set values to recommended values as needed.

Versions 11-00 or later

All the defaults of the environment setting parameters are set to their recommended values. Change the set values if you want to customize the values to better suit your environment.

However, even when JP1/AJS3 version 11-00 or later is installed, the defaults of the environment setting parameters might not be their recommended values depending on how the software was installed.

The following describes the defaults of the environment setting parameters for each method of installation:

New installation:

If you install JP1/AJS3 version 11-00 or later in a new installation, the defaults of the environment setting parameters are set to their recommended values. Depending on your environment, consider whether you need to change the set value to the values used in versions 10-50 or earlier.

Upgrade installation:

If you have JP1/AJS3 version 10-50 or earlier and install JP1/AJS3 version 11-00 or later as an upgrade installation, the default before the upgrade (the default of versions 10-50 or earlier) are set as they are. Therefore, some of the defaults of the environment setting parameters will not be their recommended values. Consider whether you need to change the set values to their recommended values. However, if you newly add a scheduler service, the defaults of the environment setting parameters for the scheduler service will be set to their recommended values. Therefore, the following environment setting parameters will have the defaults for versions 11-00 or later (recommended values) when a scheduler service is newly added, even in the case of an upgrade installation.

UNITDEFDIVIDEUPDATE

Set to yes to avoid failures due to exclusive resource shortages.

AJSPRINTSORTUNITINF

Set to yes to sort the output of the ajsprint command.

Consider whether you need to revert the set values to the values before the upgrade depending on your operations and environment.

For details about environment setting parameters whose defaults were changed to their recommended values in version 11-00, see C.2 Environment setting parameters whose defaults were changed to recommended values in version 11-00 in the JP1/Automatic Job Management System 3 Configuration Guide.

8.8 Upgrading JP1/AJS3 - Manager that uses the compatible ISAM configuration

This section describes how to upgrade JP1/AJS3 - Manager (JP1 Version 9 or later) that uses the compatible ISAM configuration.

For details about how to upgrade JP1/AJS2 - Manager (JP1 Version 8 or later) to JP1/AJS3 - Manager (JP1 Version 9 or later), see 8.5 Upgrading JP1/AJS2 - Manager to JP1/AJS3 - Manager.

8.8.1 Tasks required to upgrade JP1/AJS3 - Manager that uses the compatible ISAM configuration

This subsection describes the tasks required to upgrade JP1/AJS3 - Manager that uses the compatible ISAM configuration.

Cautionary note

Before you start upgrading JP1/AJS3 - Manager, check the OSs supported by the desired version of JP1/AJS3 - Manager. If the OS of the host on which JP1/AJS3 - Manager is installed is not supported by the desired version of JP1/AJS3 - Manager, you cannot upgrade JP1/AJS3 - Manager on that host. If you cannot perform the upgrade directly on the host, prepare a manager host on which the desired version of JP1/AJS3 - Manager is installed, and then migrate the definition information from the JP1/AJS3 - Manager that uses the compatible ISAM configuration.

(1) Tasks required to upgrade JP1/AJS3 - Manager that uses the compatible ISAM configuration to JP1/AJS3 - Manager 11-10 or later

When you upgrade JP1/AJS3 - Manager that uses the compatible ISAM configuration to version 11-10 or later, you must perform the following procedure.

Note that the steps must be performed in the following order.

Change the database configuration from the compatible ISAM configuration to the standard configuration.

JP1/AJS3 - Manager 11-10 or later no longer supports the compatible ISAM configuration. Change the database configuration to the standard configuration before upgrading the version of JP1/AJS3 - Manager.

For details about how to change the database configuration, see 8.5.2 How to set up JP1/AJS3 - Manager after upgrading from JP1/AJS2 - Manager.

Install JP1/AJS3 - Manager as an upgrade installation.

9 Notes on System Design

This chapter summarizes points to note when designing a JP1/AJS3 system.

9.1 Limits to prevent system-wide effects from external factors

In JP1/AJS3, you can implement various measures to prevent the processing of specific jobs from affecting the entire system. For example, you can discard out-of-bounds data by setting limits on the size and quantity of external data that is input to JP1/AJS3. You can also output a warning message when a constantly increasing item is nearing its limit.

The following table lists items that increase or decrease due to external factors, and the limits that can be imposed on each item in JP1/AJS3.

Table 9‒1: Items affected by external factors and specifiable limits

Category

Item

Specifiable limit

Out-of-bounds processing

Message output when the limit is reached

Standard job, action job, custom job, QUEUE job, submit job

Size of result files (standard output file, standard error output file)

(manager side)

Size of result files (standard output file; standard error output file)

A warning message is output and the received file is discarded.

KAVU2260-I#1

KAVU4294-I#1

KAVU4295-W#1

KAVU4296-E#1

Size of result files (standard output file, standard error output file)

(agent side)

Size of result files (standard output file; standard error output file)

A warning message is output and the transmitted file is discarded.

KAVU3507-I#2

KAVU3508-I#2

KAVU3509-W#2

KAVU3510-E#2

Number of jobs

Maximum number of jobs in the system;

number of warning jobs in the system

A warning message is output when the warning value is exceeded. Startup fails if the maximum value is exceeded.

KAVU4520-W#3

KAVU4524-W#3

Transfer file size

(manager side)

Transfer file size

A warning message is output and the received file is discarded.

KAVU2243-I#1

KAVU2244-E#1

Job execution time

Timeout period

The job is canceled and placed in killed status.

None

User job

Maximum data segment size per process

(UNIX only)

Dependent on the behavior of the user job.

None

Communication time

Communication timeout value

Retry based on the retry settings.

KAVU2227-E#4

KAVU2228-E#4

KAVU2245-W#4

KAVU2246-W#4

HTTP connection job

Number of jobs

Maximum number of jobs in the system;

number of warning jobs in the system

A warning message is output when the warning value is exceeded. Startup fails if the maximum value is exceeded.

KAVU4520-W#3

KAVU4524-W#3

Job execution time

Timeout period

The job is canceled and placed in killed status.

None

Communication time

Communication timeout value

Retry based on the retry settings.

KAVU2227-E#4

KAVU2228-E#4

KAVU2245-W#4

KAVU2246-W#4

QUEUE job, submit job

Number of jobs per queue

Maximum number of jobs in the queue

A warning message is output when the warning value is exceeded. Startup fails if the maximum value is exceeded.

KAVU4515-W#5

KAVU4516-W#5

Number of queues

Maximum number of defined queues

Definition error

KAVU4522-W#3

Number of agents

Maximum number of defined agents

Definition error

KAVU4521-W#3

Number of execution-locked resources

Maximum number of defined execution-locked resources

Definition error

KAVU4523-W#3

Event job

Number of satisfied start conditions

Monitoring condition (filter out unexpected events by specifying detailed conditions such as the issuing user name or output of a specific message)

An unexpected event never meets a start condition.

KAVT0273-W

KAVT0582-W

Event with a start condition

Valid range of the start condition

Monitoring ends normally.

None

Monitoring period

Timeout period

The job ends abnormally and the status of the start condition is Unmonitored + Ended.

None

File

Size of the various log files

Log file size

Data is wrapped around to the next log file.

None

#1

Output messages differ depending on the environment setting parameter specified for placing restrictions on file reception.

For details about how to limit items such as the size of received files, see 6.2.7 Placing restrictions on file reception in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 15.2.7 Placing restrictions on file reception in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

#2

The message differs depending on the environment setting parameter specified for placing restrictions on file transmission.

For details about how to limit items such as the size of transmitted file, see the section corresponding to the OS. For Windows, see 6.2.27 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide. For UNIX, see 15.2.24 Placing restrictions on file transmission in the JP1/Automatic Job Management System 3 Configuration Guide.

#3

You can use the environment setting parameters to change the setting of the maximum number of jobs in the system, the number of warning jobs in the system, the maximum number of definable queues, the maximum number of definable agents, and the maximum number of definable execution-locked resources.

For details about how to change the settings, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

#4

The output message depends on the values of the environment setting parameters that specify the retry interval and the maximum number of retries when a TCP/IP connection error occurs.

For details about how to specify these values, see 6.2.8 Changing the timeout period, interval of retries, and number of retries for TCP/IP connections in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.2.8 Changing the timeout period, interval of retries, and number of retries for TCP/IP connections in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

#5

You can use the jpqquealt command to change the maximum number of jobs in the queue.

For details about how to change the maximum number of jobs in the queue, see jpqquealt in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

9.2 Notes on JP1/AJS3 host settings

Note the following points when setting up hosts to run JP1/AJS3:

Use JP1/AJS3 only in an environment where the IP address can be resolved from the local host name; otherwise; JP1/AJS3 will fail to start.

If the character encoding used by the system is EUC and the character string displayed in the command execution result contains Japanese characters, the displayed execution result might be misaligned.

If you execute a command using a character encoding different from that of the JP1/AJS3 service, depending on the command executed, messages in both character encodings will be output to the integrated trace log.

Do not use disks mounted on file systems that are distributed over a network (such as an NFS) to store the files and directories to be created or referenced by JP1/AJS3. If you use such disks, JP1/AJS3 might not work properly. However, files and directories that are used only for the definition parameters of the following jobs can be stored on disks mounted on file systems that are distributed over a network (such as an NFS):

Execution file name for the job

Standard output file name for the job

Standard error output file name for the job

Environment file name for the job

File to transfer name for the job

Destination file name for the job

Work path for the job

Work directory for job environment settings

Home directory of the execution OS user

If the network cannot be accessed while you are using the above definition parameters, job execution might fail or be delayed.

If the OS of the host on which JP1/AJS3 operates is UNIX, NIS (Network Information Service) cannot be used for operation.

If the OS of the host on which JP1/AJS3 operates is UNIX, do not start the JP1/AJS3 service or execute commands in an execution environment for which the ulimit or limit command was used to set the upper limit for the CPU time or file size. If the upper limit of the CPU time or file size is set, any processes exceeding the set upper limit will end abnormally, causing such phenomena as the stop of the JP1/AJS3 service.

If the OS of the host on which JP1/AJS3 operates is UNIX, do not use the ulimit command to set the stack size to a value smaller than the system default.

JP1/AJS3 only operates under the condition where the stack size is at least as large as the system default size. Therefore, if you set the stack size to a size that is smaller than the system default size, any of the following problems might occur, preventing JP1/AJS3 from operating correctly:

The job fails to start or ends due to abnormal detection, and thus cannot be executed.

The job cannot be forcibly terminated.

The JP1/AJS3 service does not start.

If the OS of the host on which JP1/AJS3 operates is UNIX, do not change run level when the JP1/AJS3 service is running. In addition, do not execute rc script or inittab when the JP1/AJS3 service is running.

JP1/AJS3 uses the rc script to initialize the embedded database. Therefore, if you change the run level or start inittab processing while JP1/AJS3 is operating, the processes of JP1/AJS3 terminate abnormally.

If the OS of the host on which JP1/AJS3 operates is Solaris, in the PATH environment variable settings, do not specify /usr/ucb before specifying /usr/bin. If you specify /usr/ucb before specifying /usr/bin, JP1/AJS3 might stop functioning properly because the system assumes that commands used internally by JP1/AJS3 are in the /usr/bin directory.

In accordance with the format specified in the RFC2609 standards, use only the following types of characters for the host name of the host to be installed:

Alphabetic characters (A to Z, a to z)

Numbers (0 to 9)#1

Hyphen (-)#2

Period (.)#3

#1

Do not use a number directly after the last period.

#2

Do not use a hyphen for the first or last character of the host name.

#3

Do not use a period for the first or last character of the host name.

9.3 Notes on the JP1/AJS3 database

Note the following points in regard to the JP1/AJS3 database:

High-priority processes (the JP1/AJS3 scheduler services) can monopolize the CPU, causing JP1/AJS3 processing performance to decline. However, setting a lower priority for the JP1/AJS3 scheduler services, and a higher priority for the ajsmonsvr process and commands that operate on units, can also cause start delays in jobs and jobnets. When executing commands for operating on units, make sure you use them in an environment where they have the same priority as the scheduler services.

This can be more of an issue in UNIX, depending on the set of nice values. Note the following in regard to the nice value at process startup:

When executing a command that operates on units

Execute the command with the same nice value as the JP1/AJS3 service.

When executing, as a JP1/AJS3 job, a command that operates on a unit (including a command that operates on a unit and is executed within a script specified as a job)

Change the jobnet's Priority parameter from the default (None) to 3. If you start the JP1/AJS3 service with a nice value of 20, +20 applies to the default setting of None and corresponds to a nice value of 39 (the capped maximum), resulting in the lowest job priority. With a setting of 3, however, +0 applies and corresponds to a nice value of 20. This means that the job will be executed with the same nice value as the JP1/AJS3 service, and is less likely to monopolize the CPU.

When the configuration of the JP1/AJS3 - Manager database is the standard configuration, the system can operate for a very long time as long as the ajsembdbreclaim command is executed periodically. If the system is changed significantly (if you delete or cancel registration of a large-scale jobnet, for example), check the number of unused segments by executing the ajsembdbstatus command. When the data storage rate decreases after prolonged system operation, a message is output to the Windows event log or syslog. If necessary, reorganize the database. For details about the output messages, see 5.2.1 How to check the database usage in the JP1/Automatic Job Management System 3 Administration Guide.

For the items below, consecutive single-byte space characters placed at the end of the line might become invalid. Do not enter any spaces after a comment.

Comment of unit definition

Comment of release

Description of execution agent group

Description of execution agent

9.4 Notes when running anti-virus software

If anti-virus software imposes an exclusive control lock on a file or folder used by JP1/AJS3, the following problems might arise:

JP1/AJS3 does not start.

An exclusive control lock placed on a definition file that JP1/AJS3 references at startup might prevent JP1/AJS3 from starting.

Jobs fail to execute or are delayed.

An exclusive control lock placed on a file needed to execute a job might prevent a job from starting, cause it to terminate abnormally, or delay its execution. This problem can affect any job defined in JP1/AJS3.

JP1/AJS3 cannot generate execution schedules.

An exclusive control lock placed on the scheduler database or a file in the job error information directory might prevent JP1/AJS3 from generating a job schedule, and prevent jobs from running as scheduled.

You cannot change definitions.

An exclusive control lock placed on a JP1/AJS3 definition file might prevent you from adding or changing a job definition.

JP1/AJS3 cannot output log data.

An exclusive control lock placed on a JP1/AJS3 log file might prevent JP1/AJS3 from outputting log data, and make it difficult to troubleshoot errors.

JP1/AJS3 commands end abnormally.

An exclusive control lock placed on a file used by a JP1/AJS3 command might cause the command to end abnormally.

If you run a virus check during JP1/AJS3 operation, exclude the following files and folders. If you run a virus check while JP1/AJS3 is stopped, make sure that the anti-virus program has finished checking the following files and folders before you restart JP1/AJS3.

JP1/AJS3 - Manager files and folders

In Windows:

JP1/AJS3 - Manager log files and folders

For details about the log files and folders used by JP1/AJS3 - Manager, see 1.2.5(1) Log files and directories in Windows in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Common files and folders of JP1/AJS3 - Manager that belong to the following categories:

- Files and folders that users can reference

- Files and folders that users have no need to reference or modify

- Files and folders that are available when HP NNM linkage is used, and that users have no need to reference or modify

- Files and folders that are used for mail linkage and that are to be referenced by users and deleted and maintained during operations

- Files and folders associated with the embedded database

For details about these files and folders, see the following:

A.1(1)(a) Common files and folders in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.1(1)(b) Files when HP NNM linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.1(1)(c) Files and folders when mail linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

Files and folders specified in a job definition

Everything in a folder specified in the -d, -ld, or -bl option of the ajsembdbbuild command

For details about the ajsembdbbuild command, see ajsembdbbuild in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Everything in the folder specified in the AJSTMPDIR environment setting parameter

For details about the AJSTMPDIR environment setting parameter, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

In UNIX:

JP1/AJS3 - Manager log files and directories

For details about the log files and directories used by JP1/AJS3 - Manager, see 1.2.5(2) Log files and directories in UNIX in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Common files and directories of JP1/AJS3 - Manager that belong to the following categories:

- Files and directories that users can reference

- Files and directories that users have no need to reference or modify

- Files and folders that are available when HP NNM linkage is used, and that users have no need to reference or modify

- Files and directories that are used for mail linkage and that are to be referenced by users and deleted and maintained during operations

- Files and directories associated with the embedded database

For details about these files and directories, see the following:

A.1(2)(a) Common files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.1(2)(b) Files and directories when HP NNM linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.1(2)(c) Files and directories when mail linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

Files and directories specified in a job definition

Everything in a directory specified in the -d, -ld, or -bl option of the ajsembdbbuild command

For details about the ajsembdbbuild command, see ajsembdbbuild in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

Everything in the directory specified in the AJSTMPDIR environment setting parameter

For details about the AJSTMPDIR environment setting parameter, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

JP1/AJS3 - Agent files and folders

In Windows:

JP1/AJS3 - Agent log files and folders

For details about the log files and folders used by JP1/AJS3 - Agent, see 1.2.5(1) Log files and directories in Windows in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Common files and folders of JP1/AJS3 - Agent that belong to the following categories:

- Files and folders that users can reference

- Files and folders that users have no need to reference or modify

- Files and folders that are available when HP NNM linkage is used, and that users have no need to reference or modify

- Files and folders that are used for mail linkage and that are to be referenced by users and deleted and maintained during operations

For details about these files and folders, see the following:

A.2(1)(a) Common files and folders in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.2(1)(b) Files when HP NNM linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.2(1)(c) Files and folders when mail linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

Files and folders specified in a job definition

In UNIX:

JP1/AJS3 - Agent log files and directories

For details about the log files and directories used by JP1/AJS3 - Agent, see 1.2.5(2) Log files and directories in UNIX in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Common files and directories of JP1/AJS3 - Agent that belong to the following categories:

- Files and directories that users can reference

- Files and directories that users have no need to reference or modify

- Files and directories used when linking with HP NNM that users have no need to reference or modify

- Files and directories that are used for mail linkage and that are to be referenced by users and deleted and maintained during operations

For details about these files and directories, see the following:

A.2(2)(a) Common files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.2(2)(b) Files and directories when HP NNM linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

A.2(2)(c) Files and directories when mail linkage is used in the manual JP1/Automatic Job Management System 3 Troubleshooting

Files and directories specified in a job definition

JP1/AJS3 - View files and folders

Files and folders of JP1/AJS3 - View that belong to the following categories:

- Files and folders that users can reference

- Files and folders that users have no need to reference or modify

For details about these files and folders, see A.3 JP1/AJS3 - View files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.

JP1/AJS3 - Web Console files and folders

In Windows:

Files and folders of JP1/AJS3 - Web Console that belong to the following categories:

- JP1/AJS3 - Agent log files and folders

- Files and folders that users can reference

- Files and folders that users have no need to reference or modify

For details about these files and folders, see 1.2.5(1) Log files and directories in Windows in the manual JP1/Automatic Job Management System 3 Troubleshooting and A.4(1) In Windows in the manual JP1/Automatic Job Management System 3 Troubleshooting.

In system-drive\Program Files\Hitachi\HNTRLib2

In system-drive\Program Files (x86)\Hitachi\HNTRLib2

In UNIX:

Files and folders of JP1/AJS3 - Web Console that belong to the following categories:

- JP1/AJS3 - Agent log files and folders

- Files and folders that users can reference

- Files and folders that users have no need to reference or modify

For details about these files and folders, see 1.2.5(2) Log files and directories in UNIX in the manual JP1/Automatic Job Management System 3 Troubleshooting and A.4(2) In Linux in the manual JP1/Automatic Job Management System 3 Troubleshooting.

In /opt/hitachi/HNTRLib2/

In /var/opt/hitachi/HNTRLib2/

If you run the data collection tool while a virus check is in progress, exclude the following files and folders, in addition to those listed above, from the virus check.

Files collected for troubleshooting purposes

In Windows:

- Operating system log information required to troubleshoot JP1/AJS3 problems

- JP1-related information required to troubleshoot JP1/AJS3 problems

For details about the files that contain this information, see 1.3.1(1) Log information about the OS in the manual JP1/Automatic Job Management System 3 Troubleshooting and 1.3.1(2) Information about JP1 in the manual JP1/Automatic Job Management System 3 Troubleshooting.

In UNIX:

- Operating system log information required to troubleshoot JP1/AJS3 problems

- JP1-related information required to troubleshoot JP1/AJS3 problems

For details about the files that contain this information, see 1.3.2(1) Log information about the OS in the manual JP1/Automatic Job Management System 3 Troubleshooting and 1.3.2(2) Information about JP1 in the manual JP1/Automatic Job Management System 3 Troubleshooting.

Destination folder for data acquired by the data collection tool

9.5 Other cautionary notes

9.5.1 Notes when using JP1/AJS3 for x86 in a WOW64 environment

This subsection gives cautionary notes on using JP1/AJS3 for x86 in Windows on Windows 64 (hereafter, WOW64) environments of Windows.

When a 32-bit application is executed in a WOW64 environment, calls to the file system are redirected from %systemroot%#\system32 to %systemroot%\syswow64, and access requests to the registries HKEY_LOCAL_MACHINE\Software and HKEY_CLASS_ROOT are redirected to HKEY_LOCAL_MACHINE\Software\SysWow64 or elsewhere. That is, the operating system isolates 32-bit applications from 64-bit applications, and prevents file and registry collisions.

#

%systemroot% is an environment variable that points to the directory in which the Windows system is installed. The default setting is C:\WINDOWS.

Because JP1/AJS3 for x86 environments is a 32-bit application, calls are redirected as described above. This redirection causes the problems described in the following table.

Table 9‒2: Problems JP1/AJS3 can cause in a WOW64 environment

Problem

Affected functionality

Problem details

Even if a 64-bit program under %systemroot%\system32 is specified as an executable file, the program cannot start.

PC job (include Queueless job), QUEUE job that runs under Windows, or flexible job

Even if a file under %systemroot%\system32 is specified as the executable file for a PC job or a QUEUE job to run on Windows, access to the file is redirected to %systemroot%\syswow64. Therefore, the job fails to start or ends abnormally if no compatible 32-bit file is found under %systemroot%\syswow64. For a PC job, the following problems might occur:

Problem 1: The message KAVU4550-W is output to the integrated trace log, and the job fails to start.

This message might appear, for example, when the backup utility in the system tools (ntbackup) is executed.

Problem 2: The message This application has failed to start because netman.dll was not found. is output to the Windows event log, and the job ends abnormally with return code 128.

This message might appear, for example, when the ipconfig command in the system tools is executed.

jp1exec command

When an executable file under %systemroot%\system32 is specified in the jp1exec command, the command fails to start and the job that executed the command ends abnormally.

JP1/AJS3 - View tool execution

When an executable file under %systemroot%\system32 is registered with the command for starting a JP1/AJS3 - View tool, the command fails to start the tool.#

Files under %systemroot%\system32 can neither be referenced nor updated.

Monitoring Files job

If a file under %systemroot%\system32 is specified as a monitoring-target file# and the file is updated, monitoring access to the monitoring-target file under %systemroot%\system32 is redirected to %systemroot%\syswow64. Therefore, no event is detected, and the job remains in the running state.

Monitoring Log Files job

If a log file under %systemroot%\system32 is specified as a monitoring-target log file# and the log file is updated, monitoring access to the monitoring-target log file under %systemroot%\system32 is redirected to %systemroot%\syswow64. Therefore, no event is detected, and the job remains in the running state.

Judgment job

Even if a file under %systemroot%\system32 is specified as the judgment condition, access to the file is redirected to %systemroot%\syswow64. Therefore, the files under %systemroot%\system32 cannot be judged, and dependent units are not executed.

Standard input file for a PC job

Even if a file under %systemroot%\system32 is specified as the standard input file for a PC job, access to the file is redirected to %systemroot%\syswow64. Therefore, the standard input file cannot be found, and the job fails to start.

Standard output file for a PC job

Even if a file under %systemroot%\system32 is specified as the standard output file for a PC job, access to the file is redirected to %systemroot%\syswow64. Therefore, if JP1/AJS3 starts a 64-bit program, the program can neither reference nor update the standard output file. If, however, JP1/AJS3 starts a 32-bit program, the program can reference and update the standard output file.

Standard error output file for a PC job

Even if a file under %systemroot%\system32 is specified as the standard error output file for a PC job, access to the file is redirected to %systemroot%\syswow64. Therefore, if JP1/AJS3 starts a 64-bit program, the program can neither reference nor update the standard error output file. If, however, JP1/AJS3 starts a 32-bit program, the program can reference and update the standard error output file.

Transfer source file for a PC job

Even if a file under %systemroot%\system32 is specified as the transfer-source file for a PC job, access to the file is redirected to %systemroot%\syswow64. Therefore, the transfer-source file cannot be found, and the job fails to start.

Transfer destination file for a PC job

Even if a file under %systemroot%\system32 is specified as the transfer-destination file for a PC job, access to the file is redirected to %systemroot%\syswow64. Therefore, if JP1/AJS3 starts a 64-bit program, the program can neither reference nor update the transfer-destination file. If, however, JP1/AJS3 starts a 32-bit program, the program can reference and update the transfer-destination file.

Command

Even if a file under %systemroot%\system32 is specified as the file for command input or output, access to the file is redirected to %systemroot%\syswow64. Therefore, the specified file can neither be referenced nor updated.

Environment settings

Even if a file under %systemroot%\system32 is specified in the environment settings, access to the file is redirected to %systemroot%\syswow64. Therefore, the specified file can neither be referenced nor updated.

#

In the Files dialog box, you cannot specify a file under %systemroot%\system32.

To prevent these problems, take the following actions:

Do not specify files under %systemroot%\system32 as files to be referenced or updated by JP1/AJS3.

Specify the files under %systemroot%\sysnative instead of files under %systemroot%\system32.

Appendixes

A. List of Port Numbers

This appendix provides the tables of port numbers to be set and describes the directions of traffic through a firewall.

JP1/AJS3 uses TCP/IP.

Except for a few ports, the port numbers used by JP1/AJS3 are set by default in the services file upon shipment or when you set up a particular service.

A.1 Tables of port numbers

(1) JP1/AJS3 - Manager port numbers

The following table lists the port numbers used for JP1/AJS3 - Manager.

Table A‒1: JP1/AJS3 - Manager port numbers

Service name

Port number

Purpose

jp1ajs2qman

20241/tcp

To receive job#1 registrations

To receive a job's#1 standard output file and standard error output file

To accept requests for execution of job execution commands#2 other than jp1exec and jp1exit

To link with JP1/NQSEXEC or JP1/OJE for VOS3 (to receive job registrations)

jp1ajs2qagt

20242/tcp

To send job#1 execution requests to JP1/AJS3 - Agent

To send requests to confirm the operating status of jobs#1 to JP1/AJS3 - Agent

To send requests to check the status of jobs#1 to JP1/AJS3 - Agent

jp1ajs2qnfy

20243/tcp

To receive job#1 start/end notifications from JP1/AJS3 - Agent

jp1ajs2monitor

20244/tcp

JP1/AJS3 - Manager remote jobnet

JP1/AJS3 - Manager remote command

JP1/AJS3 - View

JP1/AJS3 - Definition Assistant

jp1ajs2report

20245/tcp

To send job#1 status notifications

To link with JP1/NQSEXEC or JP1/OJE for VOS3 (to receive job status notifications)

jp1ajs2eamgr

20246/tcp

JP1/AJS3 - Manager event job execution

jp1ajs2eaagt

20247/tcp

JP1/AJS3 - Agent event job execution

jp1ajs3cdinetd

22250/tcp

JP1/AJS3 - Web Console

jp1ajs2atmsg#3

22251/tcp

Flexible job execution

22251/udp

Flexible job broadcast execution

jp1ajs2gw

23160/tcp

To communicate between scheduler services

jp1ajs2cm#4

22275/tcp

To use JP1/AJS3 Console Manager

To receive requests from JP1/AJS3 Console View

jp1ajs2ca#4

22276/tcp

To use JP1/AJS3 Console Manager

To connect with JP1/AJS3 Console Agent

To use JP1/AJS3 Console Agent

To receive requests from JP1/AJS3 Console Manager

jp1ajs2chkman#3

23138/tcp

To use the definition pre-check function

Used by the definition pre-check function#5

jp1ajs2chkagt#3

23139/tcp

To use the definition pre-check function

Used by the definition pre-check function

jp1ajs2qlagt#3

20300/tcp

To use queueless jobs

For queueless job execution by JP1/AJS3 - Agent

jp1ajs2qlftp#3

20301/tcp

To use queueless jobs

For queueless file transfer from JP1/AJS3 - Manager

None#6

22220/tcp

To communicate with an embedded database that has been configured during the new installation#7

Note

When activating multiple scheduler services within a single logical host, separately assign ports to each jp1ajs2report service. Then specify the service name of the job status notification port set in the JP1/AJS3 - Manager environment settings.

#1

Standard job, submit job, HTTP connection job, action job, or custom job.

#2

See the table of job execution commands in 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

#3

Not set at JP1/AJS3 - Manager installation. The port is set when you set up the functionality.

#4

Set during installation in the Windows version only. In UNIX, this is set when JP1/AJS3 Console is set up. JP1/AJS3 Console is functionality used for compatibility.

#5

In UNIX, the definition pre-check function does not use the port number for jp1ajs2chkman. In Windows, the port number for jp1ajs2chkman is used for communication within the same server.

#6

Not registered in services.

#7

If you have configured the embedded database by executing the jajs_setup, jajs_setup_cluster, and jajs_migrate commands, use the port numbers described in 2.6.5 Database settings that are set up in JP1/AJS3. If you have performed an advanced setup to configure the embedded database, use the port number specified by the -p option of the ajsembdbbuild command.

(2) JP1/AJS3 - Agent port numbers

The following table lists the port numbers used for JP1/AJS3 - Agent.

Table A‒2: JP1/AJS3 - Agent port numbers

Service name

Port number

Purpose

jp1ajs2qman

20241/tcp

To send a job's#1 standard output file and standard error output file to JP1/AJS3 - Manager

To send requests to JP1/AJS3 - Manager for job execution commands#2 other than jp1exec and jp1exit

jp1ajs2qagt

20242/tcp

To accept job#1 execution requests

To accept requests to confirm the operating status of jobs#1

To accept requests to check the status of jobs#1

jp1ajs2qnfy

20243/tcp

To send job#1 start/end notifications to JP1/AJS3 - Manager

jp1ajs2eamgr

20246/tcp

JP1/AJS3 - Manager event job execution

jp1ajs2eaagt

20247/tcp

JP1/AJS3 - Agent event job execution

jp1ajs2atmsg#3

22251/tcp#4

Flexible job execution

22251/udp#4

Flexible job broadcast execution

jp1ajs2chkagt#3

23139/tcp

To use the definition pre-check function

Used by the definition pre-check function

jp1ajs2qlagt#3

20300/tcp#4

To use queueless jobs

For queueless job execution by JP1/AJS3 - Agent

jp1ajs2qlftp#3

20301/tcp#4

To use queueless jobs

For queueless file transfer from JP1/AJS3 - Manager

Note

The following service names may be added to the services file (or the /etc/services file in UNIX), but can be deleted because they are not used in JP1/AJS3 - Agent:

Service name: jp1ajs2monitor, port number: 20244

Service name: jp1ajs2report, port number: 20245

Service name: jp1ajs2gw, port number: 23160

Service name: jp1ajs3cdinetd, port number: 22250

#1

Standard job, submit job, HTTP connection job, action job, or custom job.

#2

See the table of job execution commands in 1.5 Commands in the manual JP1/Automatic Job Management System 3 Command Reference.

#3

Not set at JP1/AJS3 - Agent installation. The port is set when you set up the functionality.

#4

JP1/AJS3 - Agent Minimal Edition does not use this port number because JP1/AJS3 - Agent Minimal Edition cannot execute flexible and queueless jobs.

(3) JP1/AJS3 - View port number

The following table lists the port number used for JP1/AJS3 - View.

Table A‒3: JP1/AJS3 - View port number

Service name

Port number

Purpose

jp1ajs2monitor

20244/tcp

JP1/AJS3 - View

jp1ajs2cm#

22275/tcp

To use JP1/AJS3 Console View

To connect to JP1/AJS3 Console Manager

Note

The following service names are added to the services file, but can be deleted because they are not used in JP1/AJS3 - View:

Service name: jp1ajs2cfm, port number: 20450

#

JP1/AJS3 Console is functionality used for compatibility.

(4) JP1/AJS3 - Web Console port number

The following table lists the port number used for JP1/AJS3 - Web Console.

Table A‒4: JP1/AJS3 - Web Console port number

Service name

Port number

Purpose

jp1ajs3web

22252/tcp

To receive requests from a web browser (when SSL communication is not used)

jp1ajs3webssl

22253/tcp

To receive requests from a web browser (when SSL communication is used)

jp1ajs3webapp

22254/tcp

To connect the HTTP server with the web application server (J2EE server) within the Web Console server

jp1ajs3internalserver

22255/tcp

To internally manage the web application server (J2EE server)

jp1ajs3rmiserver

23152/tcp

To internally manage the web application server (J2EE server)

A.2 Directions of traffic through a firewall

The following table lists the directions of traffic through a firewall.

JP1/AJS3 supports both packet filtering and NAT (static mode) address translation methods.

Table A‒5: Directions of traffic through a firewall (JP1/AJS3)

Program name to be set

Service name

Port number

Direction of the firewall traffic

JP1/AJS3 - Manager

JP1/AJS3 - Agent

Another program#1

jp1ajs2qman

20241/tcp

Agent -> Manager

Manager <--> Manager

Manager <--> Another program#1

JP1/AJS3 - Manager

JP1/AJS3 - Agent

jp1ajs2qagt

20242/tcp

Manager -> Agent

JP1/AJS3 - Manager

JP1/AJS3 - Agent

jp1ajs2qnfy

20243/tcp

Agent -> Manager

JP1/AJS3 - Manager

JP1/AJS3 - View

JP1/AJS3 - Definition Assistant#2

jp1ajs2monitor

20244/tcp

Manager <--> Manager

JP1/AJS3 - View -> Manager

JP1/AJS3 - Definition Assistant#2 -> Manager

JP1/AJS3 - Manager

Another program#1,#3

jp1ajs2report#4

20245/tcp

Manager <--> Manager

Another program#1,#3 -> Manager

JP1/AJS3 - Manager

jp1ajs2gw

23160/tcp

The requesting manager of the host on which a jobnet connector to be connected is defined <--> Connection-destination manager to which the Jobnet connector connects

JP1/AJS3 - Manager

JP1/AJS3 - Agent

jp1ajs2eamgr

20246/tcp

Agent -> Manager

JP1/AJS3 - Manager

JP1/AJS3 - Agent

jp1ajs2eaagt

20247/tcp

Manager -> Agent

JP1/AJS3 - Manager

JP1/AJS3 - Agent#5

jp1ajs2qlagt

20300/tcp

Manager -> Agent

JP1/AJS3 - Manager

JP1/AJS3 - Agent#5

jp1ajs2qlftp

20301/tcp

Agent -> Manager

JP1/AJS3 - Manager

JP1/AJS3 - Agent

jp1ajs2chkagt

23139/tcp

Manager -> Agent

JP1/AJS3 - Manager

JP1/AJS3 - Web Console

jp1ajs3cdinetd

22250/tcp

JP1/AJS3 - Web Console -> Manager

JP1/AJS3 - Manager

JP1/AJS3 - Agent#5

jp1ajs2atmsg

22251/tcp

Relay agent (if relaying) <--> Destination agent

Relay agent (if relaying) <--> Broadcast agent

Manager (if not relaying) <--> Destination agent

Manager (if not relaying) <--> Broadcast agent

Broadcast agent <--> Destination agent

JP1/AJS3 - Manager

JP1/AJS3 - Agent#5

jp1ajs2atmsg

22251/udp

Broadcast agent <--> Destination agent

JP1/AJS3 - Web Console

Web browser

jp1ajs3web

22252/tcp

Web browser -> JP1/AJS3 - Web Console

JP1/AJS3 - Web Console

Web browser

jp1ajs3webssl

22253/tcp

Web browser -> JP1/AJS3 - Web Console

Legends:

->: One-way, from the left to the right

<-->: Two-way, from the left to the right, or the right to the left

#1

Another program refers to JP1/NQSEXEC or JP1/OJE for VOS3, which is a product intended for job cooperation.

For details, see the Job Management Partner 1/NQSEXEC System Administrator's Guide or Job Management Partner 1/NQSEXEC User's Guide when you use JP1/NQSEXEC. When you use JP1/OJE for VOS3, see the Job Management Partner 1/Open Job Entry Description, User's Guide and Reference, for VOS3 systems.

#2

For details about setting up a firewall, see the JP1/Automatic Job Management System 3 - Definition Assistant Description, Operator's Guide and Reference.

#3

Assume that the other program is to receive the status reports on the jobs registered from the other program in JP1/AJS3 - Manager. In such a case, the traffic through the job-status reporting port specified by the other program must be in the direction from JP1/AJS3 - Manager to the other program.

#4

When you activate multiple scheduler services or change the job status reporting port (jp1ajs2report by default) for the scheduler service, open the ports for these services or the changed port as performed for the jp1ajs2report port.

#5

JP1/AJS3 - Agent Minimal Edition does not use this port, and, therefore, does not require the settings for the traffic through a firewall.

To allow connections over a firewall using the port numbers in the above table, set up the firewall to permit traffic via the port corresponding to the service name and ANY replies to the session established for the port corresponding to the service name. The ANY reply comes about because the OS automatically assigns numbers.

Note the following when installing JP1 products on a firewall server.

Internal communication is also subject to firewall control in some cases. When installing JP1/AJS3 on a server with a firewall, set up the firewall to permit communication between internal processes within the server.

In the case of Windows JP1/AJS3 - Manager, internal processing within the same computer dynamically uses an empty port to carry out local communication at IP address 127.0.0.1 (local host). If the firewall also regards local communication (at 127.0.0.1) as the target of access restriction, set the firewall so as to permit all communications at 127.0.0.1 in addition to the setting mentioned in step 1.

In the case of JP1/AJS3 - Manager, the internal processing within the same computer for, for example embedded-database processes, uses port numbers that are automatically assigned by the OS. To prevent rejection of these port numbers by a firewall, ensure that all communications within the same computer are permitted. Note that the range of port numbers automatically assigned by an OS varies according to the OS. For details, see the manuals for the applicable OSs.

When an option to change the startup method for Jobnet Monitor is enabled in JP1/AJS3 - View, JP1/AJS3 - View dynamically uses an empty port number during the local communications at IP address 127.0.0.1 (localhost). If the firewall restricts local communications (communications at 127.0.0.1), permit all communications at 127.0.0.1.

A.3 Ports used for communications between JP1/AJS3 - View and JP1/AJS3 - Manager

The following describes the ports used for communications between JP1/AJS3 - View and JP1/AJS3 - Manager.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - View to JP1/AJS3 - Manager.

Table A‒6: Port numbers for communications from JP1/AJS3 - View to JP1/AJS3 - Manager

Service name

Default port number

jp1ajs2monitor

20244/tcp

You can change these port numbers as desired.

A.4 Ports used for communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent

The following describes the ports used for communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Agent to JP1/AJS3 - Manager.

Table A‒7: Port numbers for communications from JP1/AJS3 - Agent to JP1/AJS3 - Manager

Service name

Default port number

jp1ajs2qman

20241/tcp

jp1ajs2qnfy

20243/tcp

jp1ajs2eamgr

20246/tcp

jp1ajs2qlftp

20301/tcp#

jp1ajs2atmsg

22251/tcp#

#

JP1/AJS3 - Agent Minimal Edition does not use this port number because JP1/AJS3 - Agent Minimal Edition cannot execute flexible and queueless jobs.

You can change these port numbers as desired.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Manager to JP1/AJS3 - Agent.

Table A‒8: Port numbers for communications from JP1/AJS3 - Manager to JP1/AJS3 - Agent

Service name

Default port number

jp1ajs2qagt

20242/tcp

jp1ajs2eaagt

20247/tcp

jp1ajs2qlagt

20300/tcp#

jp1ajs2atmsg

22251/tcp#

jp1ajs2chkagt

23139/tcp

#

JP1/AJS3 - Agent Minimal Edition does not use this port number because JP1/AJS3 - Agent Minimal Edition cannot execute flexible and queueless jobs.

You can change these port numbers as desired.

A.5 Ports used for communications between JP1/AJS3 - Manager and JP1/AJS3 - Manager

The following describes the ports used for communications between JP1/AJS3 - Manager and JP1/AJS3 - Manager.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Manager to JP1/AJS3 - Manager.

Table A‒9: Port numbers for communications from JP1/AJS3 - Manager to JP1/AJS3 - Manager

Service name

Default port number

jp1ajs2qman

20241/tcp

jp1ajs2monitor

20244/tcp

jp1ajs2report

20245/tcp

jp1ajs2gw

23160/tcp

You can change port numbers as desired.

When using JP1/AJS3 - Manager as an agent, set the communication ports listed in A.4 Ports used for communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

A.6 Port used for communications between JP1/AJS3 - View and JP1/Base

There is no port used in communications between JP1/AJS3 - View and JP1/Base.

A.7 Port used for communications between JP1/AJS3 - Agent and JP1/AJS3 - Agent

(1) Port used for communications between JP1/AJS3 - Agent (relay agent) and JP1/AJS3 - Agent (destination agent)

The following describes the ports used for communications between JP1/AJS3 - Agent (relay agent) and JP1/AJS3 - Agent (destination agent) when flexible jobs are used. Note that JP1/AJS3 - Agent Minimal Edition does not use this port.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (destination agent).

Table A‒10: Port numbers for communications from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (destination agent)

Service name

Default port number

jp1ajs2atmsg

22251/tcp

(2) Port used for communications between JP1/AJS3 - Agent (relay agent) and JP1/AJS3 - Agent (broadcast agent)

The following describes the ports used for communications between JP1/AJS3 - Agent (relay agent) and JP1/AJS3 - Agent (broadcast agent) when flexible jobs are used. Note that JP1/AJS3 - Agent Minimal Edition does not use this port.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (broadcast agent).

Table A‒11: Port numbers for communications from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (broadcast agent)

Service name

Default port number

jp1ajs2atmsg

22251/tcp

(3) Port used for communications between JP1/AJS3 - Agent (broadcast agent) and JP1/AJS3 - Agent (destination agent)

The following describes the ports used for communications between JP1/AJS3 - Agent (broadcast agent) and JP1/AJS3 - Agent (destination agent) when flexible jobs are used. Note that JP1/AJS3 - Agent Minimal Edition does not use this port.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Agent (broadcast agent) to JP1/AJS3 - Agent (destination agent).

Table A‒12: Port numbers for communications from JP1/AJS3 - Agent (broadcast agent) to JP1/AJS3 - Agent (destination agent)

Service name

Default port number

jp1ajs2atmsg

22251/tcp

22251/udp

A.8 Port used for communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager

The following describes the ports used for communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager.

The following table lists the service names and default port numbers for communications from JP1/AJS3 - Web Console to JP1/AJS3 - Manager.

Table A‒13: Port numbers for communications from JP1/AJS3 - Web Console to JP1/AJS3 - Manager

Service name

Default port number

jp1ajs3cdinetd

22250/tcp

You can change these port numbers as desired.

A.9 Ports used for communications between a web browser and JP1/AJS3 - Web Console

The following describes the ports used for communications between a web browser and JP1/AJS3 - Web Console.

The following table lists the service names and default port numbers for communications from a web browser to JP1/AJS3 - Web Console.

Table A‒14: Port numbers for communications from a web browser to JP1/AJS3 - Web Console

Service name

Default port number

jp1ajs3web

22252/tcp

jp1ajs3webssl

22253/tcp

You can change these port numbers as desired.

B. List of Limits

B.1 Limits on the number of JP1/AJS3 product connections

The following table shows the number of JP1/AJS3 - Agents, JP1/AJS3 - Views and JP1/AJS3 - Web Consoles that can be connected to JP1/AJS3 - Manager.

Table B‒1: Limits of JP1/AJS3 - Agents, JP1/AJS3 - Views and JP1/AJS3 - Web Consoles that can be connected to JP1/AJS3 - Manager

Definition

Maximum

Number of JP1/AJS3 - Agents that can be connected to a single JP1/AJS3 - Manager (or single logical host in a cluster configuration)

1,024#1

Number of JP1/AJS3 - Views that can be connected to a single JP1/AJS3 - Manager (or single logical host in a cluster configuration)

50#2

Number of JP1/AJS3 - Web Console that can be connected to a single JP1/AJS3 - Manager (or single logical host in a cluster configuration)

32#3,#4

#1

For the agents specified as destination agents for any of the following jobs, you can increase the maximum number of agents that can be connected to 2,048 by specifying a setting for the AGENTLIMITEXTEND environment setting parameter.

PC, UNIX, or action job for which Standard is specified for Exec. Service

Event job

Custom Job

HTTP Connection Job

Flexible Job

#2

You can increase the maximum number of connections to 128 by specifying a setting for the MAXSESSION environment setting parameter. Connecting 64 or more JP1/AJS3 - Views will greatly increase the load on JP1/AJS3 - Manager and the network. Therefore, if you want to connect 64 or more JP1/AJS3 - Views, prohibit JP1/AJS3 - Views from automatically refreshing their screens or set the automatic refresh interval to 600 seconds or longer. Also, do not use JP1/AJS3 - Manager and the Monthly Schedule window simultaneously, since the window transfers a large amount of data.

#3

You can increase the maximum number of connections to 100 by specifying a setting for the CDMAXSESSION environment setting parameter.

#4

For details about the maximum number of units that can be monitored using JP1/AJS3 - Web Console, see 6.5 Features of and differences between jobnet monitoring programs in the manual JP1/Automatic Job Management System 3 Overview.

The following table shows the maximum number of JP1/AJS3 - Managers that can be connected to JP1/AJS3 - Agent.

Table B‒2: Limit of JP1/AJS3 - Managers that can be connected to JP1/AJS3 - Agent

Definition

Maximum

Number of JP1/AJS3 - Managers that can be connected to a single JP1/AJS3 - Agent

16#

#

The maximum value assumes an environment in which the agent and all managers can communicate smoothly with each other. If there is a manager for which name resolution by the agent takes time or a manager for which a timeout occurs during a connection, operation might be affected even when the number of managers is fewer than the maximum. For example, execution of a job from another manager might be delayed. Also, the number of jobs concurrently processed by the agent might affect operation. Make sure that you consider the load on the system during peak times and configure the system accordingly. Note that for a queueless-job execution environment, the number of JP1/AJS3 - Managers that can be connected is not limited.

B.2 Limits related to the entire JP1/AJS3 system

For details about the language types and character encodings that you can use with JP1/AJS3, see 2.4.2 Language type and character encoding of the system.

The following figure shows other limits related to the entire JP1/AJS3 system.

Table B‒3: Limits related to the entire JP1/AJS3 system

Definition

Maximum

Physical host name

63 (bytes)

Logical host name

32 (bytes)

B.3 Limits for units

The following table lists the limits of units defined in JP1/AJS3.

Table B‒4: Limits of units

Definition

Maximum

Comment length for a unit

80 (bytes)#1

Number of units that can be defined in one level of hierarchy below the job group

Not limited

Number of units that can be defined in one level of hierarchy below the jobnet#2

10,000

Number of root jobnets that can be defined

Not limited

Job group name#3 (full name)

930 (bytes)#4

Jobnet name#3 (full name)

930 (bytes)#4

Job name#3 (full name)

930 (bytes)

Maximum number of nests of unit#2

30#5

Unit name

30 (bytes)#1

Number of jobnets that can be registered for execution

2,147,483,647#6

Number of logs to keep

99 (or 999#7, #8)

Number of backup boxes that can be created

Not limited

Number of backup files that can be created in a backup box

1,024

Scheduler log file capacity

2,048,000,000 (bytes)

Last date

2036/12/31

Maximum number of scheduled generations in a single jobnet

7,680#8

Maximum number of concurrently monitored generations waiting for start conditions to be satisfied

7,680#9

Number of queuing jobs and running jobs that can be executed concurrently

Maximum value of MaximumContentJob #6, #11

Number of event jobs that can be defined in start conditions

32

Number of units whose ends are being waited for and that can be set for one unit with a wait condition

32

Maximum number of generations per day for which the temporary change operation management function can store temporary change information #10

999

Length of the TZ environment variable

95 (bytes)

Length of a host name

255 (bytes)

Length of the LANG environment variable

58 (bytes)

#1

If UTF-8 encoding is used and sjis is specified for the DEFLENTYPE environment setting parameter, this value is the number of bytes that is converted to Shift-JIS.

#2

The value used for multiplying the horizontal and vertical sizes of the map area set in the Jobnet Editor window is the number of units that can be defined in one level of hierarchy.

Creating many units in one root jobnet might have an operational impact, such as insufficient memory, because a large amount of information needs to be processed. We recommend that you create no more than 40,000 job network elements in one root jobnet.

#3

Alphanumeric characters, multi-byte characters, and the following symbols can be used to define unit names:

! # $ % + @ - (hyphen) . (period) _ (underscore)

The following symbols are also available. However, these are provided for migration from previous JP1/AJS product. Do not use the symbols for other purposes.

" & ' * < > ? [ \ ] ^ ` { | } ~

When specifying a unit name containing any of these symbols in the command line of a command that manipulates a unit, enclose the entire unit name in double quotation marks (") and cast the unit name with a backslash (\) before each symbol. For example, to specify unit /net[1] in the ajsprint command, write as follows: ajsprint "/net\[1\]"

Note that some symbols have special meanings to command interpreters such as UNIX shells. In this case, avoid using such symbols for unit names since they might generate incorrect operations.

Periods (.) and at signs (@) are not allowed at the beginning of unit names, except for .CONDITION used as the unit name of a start condition.

Characters that are specific to computers cannot be used for unit names. In addition to unit names, we recommend that you do not use computer-dependent characters for any definition items, since they might become garbled.

#4

When the maximum number is reached, no lower units can be created.

#5

The limit is 10 if UTF-8 encoding is used and sjis is specified for the DEFLENTYPE environment setting parameter.

#6

This value is calculated independent of resources such as disks and memory, and execution performance.

#7

This is the maximum value available with the extended function for the number of logs to keep.

#8

In accordance with the database restrictions, the total number of logs to keep and scheduled generations cannot exceed 8,000.

With an extended function, the maximum number of logs to keep can be increased to 999. However, if the number of scheduled generations is set to a maximum of 7,680, the maximum permissible number of logs to keep is decreased to 320. Such a restriction is provided to prevent deletion of schedules that are already registered for fixed execution. To increase the maximum permissible number of logs to keep using the extended function, manage operations so as to limit the future schedules to 7,001 or less.

#9

This value indicates the maximum number of concurrently monitored generations waiting for start conditions to be satisfied.

Normally when a generation satisfies the start conditions and begins to run, the generation is excluded from the generations that are subject to this limit.

#10

The temporary change operation management function can store temporary change information for a maximum of 999 generations per day for one root jobnet. If you attempt to make temporary changes to the 1,000th and later generations, an error occurs and the temporary change information will not be stored. When you use the temporary change operation management function, make sure the number of generations executed per day by one root jobnet does not exceed 999.

#11

This value is also the maximum value that can be specified for the MaximumContentJob environment setting parameter. For details about the MaximumContentJob environment setting parameter, see 20.5.2(12) MaximumContentJob in the JP1/Automatic Job Management System 3 Configuration Guide.

B.4 Limits for scheduler services

The following table lists the limits for scheduler services.

Table B‒5: Limits for the scheduler service

Definition

Maximum

Maximum number of scheduler services defined

20#

#

The maximum number of scheduler services that can be defined per computer (physical and logical hosts) is 20.

B.5 Limits for the job execution environment

The following table lists the limits for executing Unix jobs, PC jobs, flexible jobs#, HTTP connection jobs, event jobs, action jobs, and custom jobs in JP1/AJS3.

#

For a flexible job, replace execution agent with relay agent.

Table B‒6: Limits for the job execution environment

Definition

Maximum

Number of registered execution agents

1,024#1,#2

Number of registered execution agent groups

1,024

Number of agent hosts that can be specified for one execution agent

1

Number of execution agents that can be grouped in an execution agent group

1,024#2

#1

Because the default execution agent is defined when JP1/AJS3 is set up, the ajsagtadd command can be used to add 1,023 agents.

Note that the default execution agent cannot be deleted. For details on the default execution agent, see 2.5.1(3) Default execution agent.

#2

By using the environment setting parameter AGENTLIMITEXTEND, you can increase the maximum number of agents that can be connected to a single JP1/AJS3 - Manager to 2,048.

B.6 Limits for the submit job execution environment

The following table lists the limits for executing QUEUE jobs and submit jobs.

Table B‒7: Limits for the submit job execution environment

Definition

Maximum

Maximum number of queues defined

8,192

Number of connectable agents

1,024

Number of execution-locked resources

8,192

B.7 Limits for queueless job execution control

The following table shows the limit for executing queueless jobs in JP1/AJS3.

Table B‒8: Limit for queueless job execution control

Definition

Maximum

Number of logical hosts that can be attached concurrently to the queueless agent service

9

B.8 Limits for the event/action control

The following table lists the limits for executing event jobs in JP1/AJS3.

Table B‒9: Limits for the event/action control

Item

Maximum

Number of event jobs (including those set in start conditions) that can be concurrently registered for execution or forcibly terminated on an agent host from one or more manager hosts

1,000#1

Number of event jobs (including those set in start conditions) that can be concurrently registered for execution or forcibly terminated on multiple agent hosts from one manager host

4,000#1

Maximum number of event jobs (including those set in start conditions) executed on one agent host that can continue to run through the warm-start or hot-start process of a JP1/AJS3 service or scheduler service on a manager host

1,000#1

Maximum number of event jobs (including those set in start conditions) that can continue to run through the warm-start or hot-start process of a JP1/AJS3 service or scheduler service on a manager host, per scheduler service

4,000#1

Maximum number of event jobs (including those set in start conditions) that can continue to run through the warm-start or hot-start process of a JP1/AJS3 service or scheduler service on a manager host, per manager host

80,000#1

Maximum number of event jobs (including those set in start conditions) executed on one agent host that can continue to run through the restart process of a JP1/AJS3 service on an agent host, per agent host

1,000#1

Maximum number of event jobs (including those set in start conditions) executed on one agent host that can continue to run through the execution of the jajs_maintain command with the -F option specified

--

Maximum number of event jobs (including those set in start conditions) that can continue to run through the execution of the jajs_maintain command with the -F option specified per scheduler service

--

Maximum number of event jobs (including those set in start conditions) that can continue to run through the execution of the jajs_maintain command without the -F option specified per manager host

--

Number of ajskill or ajsintrpt commands that can be executed consecutively on event jobs (including those set in start conditions)

4,000#1, #2

Number of Monitoring Log Files jobs that can be executed concurrently on one execution host

150#3

Number of email reception monitoring job that can be executed concurrently on one execution host

60

Legend:

--: Not applicable

#1

The value when no events have occurred. If events are likely to occur at the same time, configure the system so that the maximum value, counting events and event jobs, will not be exceeded.

If the maximum is exceeded, and an operation is performed on an event job, or an event job (including an event job in a start condition) detects the monitored event, the following issues might occur:

Event jobs registered for execution (including those in start conditions) remain in queuing status.

Active event jobs, and jobnets with start conditions that JP1/AJS3 is monitoring, fail to end when killed.

Event jobs (including those in start conditions) do not detect monitored events.

Be aware of these issues, but note that in some high-performance environments, exceeding any of the limits might not cause problems.

These issues are due to the high volume of communication that takes place in the processing of a large number of jobs. For details about what causes the issues and recovery procedures, see 7.6.8 Notes on restarting the JP1/AJS3 service while event jobs are running in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

#2

Executing these commands consecutively over a short duration results in a high volume of communication. If the maximum value is exceeded, the issues in #1 above might occur. For details about what causes the issues and recovery procedures, see 7.6.8 Notes on restarting the JP1/AJS3 service while event jobs are running in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

#3

This is the maximum value under the following conditions:

The Monitoring Log Files jobs run under Windows.

Each Monitoring Log Files job monitors one log file only.

Log files are monitored by Monitoring Log Files jobs only, not in conjunction with the JP1/Base log file trapping function.

In UNIX, when one Monitoring Log Files job monitors multiple log files, or is used in conjunction with the JP1/Base log file trapping function, estimate the number of Monitoring Log Files jobs that can be executed based on the number of log files that can be monitored by the log file trapping function. For details, see the JP1/Base User's Guide.

B.9 Limits for the definition pre-check function

The following table describes the limit for pre-checks on JP1/AJS3 definitions.

Table B‒10: Limit for definition pre-check

Definition

Maximum number

Number of definition pre-checks that can be executed simultaneously

1

B.10 Limits for using operation profiles

The following tables describe the limits for using operation profiles.

Table B‒11: Limits for using an execution agent profile

Definition

Maximum number

Number of units that can be set for an execution agent profile

128 (units)

File size for an execution agent profile

5 (megabytes)

Record length for an execution agent profile

2,047 (bytes)#

#

The number of bytes does not include linefeed characters (LF: 0x0a and CR: 0x0d) if they exist. If no linefeed characters exist, the maximum record length is 2,048 bytes.

Table B‒12: Limits for using a unit-attribute profile

Definition

Maximum number

Number of units that can be set for a unit-attribute profile

128 (units)

File size for a unit-attribute profile

10 (megabytes)

Record length for a unit-attribute profile

2,047 (bytes)#

#

The number of bytes does not include linefeed characters (LF: 0x0a and CR: 0x0d) if they exist. If no linefeed characters exist, the maximum record length is 2,048 bytes.

B.11 Limits on file sizes

For JP1/AJS3 for Windows, if you enable the LARGEFILEUSE environment setting parameter, you can use large files (files exceeding 2 GB) for the following:

Monitoring target files for a monitoring files job

You can use large files for the following, regardless of the value of the LARGEFILEUSE environment setting parameter.

Files used for judgment conditions for judgment jobs

For version 11-10 or later of JP1/AJS3 for Linux, HP-UX, AIX and Solaris, you can use large files for the following, regardless of the value of the LARGEFILEUSE environment setting parameter (the value yes is always assumed).

Monitoring target files for a monitoring files job

Files used for judgment conditions for judgment jobs

For details, see 6.3.16 Enabling monitoring of a large file in the JP1/Automatic Job Management System 3 Configuration Guide.

Note that the following embedded-database files might become large files:

Files under the data area storage directory when the embedded database is large-scale database

Files under the data area storage directory (when the function for automatically expanding the database is used)

Files under the system area directory (when the function for automatically expanding the system log is used)

Backup files

Unload files (when database reorganization is performed)

Unload log files (when restoring the scheduler database from unload log files)

C. Functions and Operating Modes for Verifying the Legitimacy of JP1/AJS3 Operations

Historical information for verifying the legitimacy of operations performed in JP1/AJS3 is output to the scheduler log. Using this information, you can check whether your JP1/AJS3 system has been used for illegal activities.

This appendix discusses the functions, settings, and operating modes you can use to verify that JP1/AJS3 operations are legitimate.

C.1 Functions for verifying the legitimacy of JP1/AJS3 operations

The following describes the functions you can use for verifying the legitimacy of JP1/AJS3 operations.

(1) Outputting extended information to scheduler log files

In the environment settings, you can specify parameters for extended output to scheduler log files. You can then use the information to verify that JP1/AJS3 operations are legitimate.

The following table describes the additional information that you can output, and the required parameter setting for each extended function.

Table C‒1: Additional information output to the scheduler log and required parameter settings

Extended function

Parameter to set

Output connection start/end messages from JP1/AJS3 - Web Console and JP1/AJS3 - View.

Set all in the environment setting parameter MONLOG to output messages to a scheduler log file.

Set all in the environment setting parameter MONSYSLOG to output messages to syslog or Windows event log.

Output user authentication messages.

Set all in the environment setting parameter AUTHLOG to output messages to a scheduler log file#1.

Set all in the environment setting parameter AUTHSYSLOG to output messages to syslog or Windows event log.

Output the following additional information to the unit execution log and operation log:#2

Operation user type

Mapped OS user type

Requester IP address#3

IP address of the host that requested an operation

Requester ID information#3

Information identifying the product or function that requested an operation

Command options

Options specified when executing a command

Unit name

Name of the target unit

Set yes in the environment setting parameter AJSLOGOUTPUTEXTEND.

Output the date in year/month/day format to a scheduler log (the default format is month/day).

Set yes in the environment setting parameter AJSLOGOUTPUTYEAR.

Output start/end messages about the scheduler log output process.

Set all in the environment setting parameter LOGDLOG to output messages to a scheduler log file.

Set all in the environment setting parameter LOGDSYSLOG to output messages to syslog or Windows event log.

Output the start/end messages about the scheduler log output processes for each host.

Set all in the environment setting parameter HLOGDLOG to output messages to a scheduler log file for each host.

Set all in the environment setting parameter HLOGDSYSLOG to output messages to syslog or Windows event log.

Output an execution log of commands executed while the scheduler service was stopped.

Set host in the environment setting parameter AJSLOGOUTPUTDEST.

#1

Output to the scheduler log for each host.

#2

When this function is enabled and a value other than none is set in the environment setting parameter REFLOG, a message about the reference operation that was executed when a unit ended abnormally is output.

#3

The requesting host's IP address and ID information are not output to the log if the operation was performed from the local computer.

For details about performing these settings, see 4.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows systems) or 14.2 Environment setting parameter settings in the JP1/Automatic Job Management System 3 Configuration Guide (for UNIX systems).

For details about the environment setting parameters, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

For details about the contents of scheduler log files, see C.1 Log entries output by the scheduler services in the manual JP1/Automatic Job Management System 3 Troubleshooting.

(2) Outputting the last update time of unit definitions

You can output the last update time of unit definitions in either of two ways:

Using the ajsprint command

By executing the ajsprint command with the -f option specified, you can acquire the last update time of all the lower-level units of the specified unit.

For the command syntax, see ajsprint in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

Import unit definitions in JP1/AJS3 - Definition Assistant

When you import unit definition information using JP1/AJS3 - Definition Assistant, the last update time of each unit is output to the log.

You can edit the output last update times, but not when exporting the imported unit definition information.

For details about how to import unit definitions in JP1/AJS3 - Definition Assistant, see the manual JP1/Automatic Job Management System 3 - Definition Assistant.

You can also hide the last update-time field in the imported unit definition information. This field is displayed by default. To hide the last update times:

Open the following file in an editor:

JP1/AJS3-Definition-Assistant-installation-folder\conf\ajs2da.conf

Set N in the parameter TYPE-LASTUPDATE=.

Save the settings.

(3) Extracting log information for verifying JP1/AJS3 operations

Using the ajslogprint command, you can extract information needed for verifying JP1/AJS3 operations from the scheduler log and output the information to a file.

For the command syntax, see ajslogprint in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(4) Checking the job information about QUEUE jobs and submit jobs

You can use the jpqendjobshow command to output the job information about QUEUE jobs and submit jobs to the standard output.

For the command syntax, see jpqendjobshow in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference

C.2 Recommended system configurations

The following figure shows an example of a recommended system configuration for using the functions for verifying the legitimacy of operations performed in JP1/AJS3.

Figure C‒1: Recommended device configuration

The configuration in this example has the development and production environments on different hosts. Using JP1/AJS3 - Definition Assistant, import unit definition information from JP1/AJS3 - Manager on the development host, and then edit the information, or create new unit definitions. Next, test the unit definitions you edited or created by exporting them back to JP1/AJS3 - Manager on the development host. If the test is successful, change the host name and other settings in the unit definitions to match the production environment, and then export the unit definitions to JP1/AJS3 - Manager on the production host.

With this kind of configuration, to use the logging functions for verifying JP1/AJS3 operations, the following products must be installed in the corresponding hosts in both the development and production environments:

JP1/AJS3 - Manager 09-00 or later, or JP1/AJS2 - Manager 08-10 or later

JP1/Base 08-10 or later

In addition, the following product is required on the unit definition management server:

JP1/AJS3 - Definition Assistant 09-00 or later, or JP1/AJS2 - Definition Assistant 08-10 or later

For details about importing and exporting unit definitions in JP1/AJS3 - Definition Assistant or JP1/AJS2 - Definition Assistant, see the manual JP1/Automatic Job Management System 3 - Definition Assistant or JP1/Automatic Job Management System 2 - Definition Assistant.

C.3 Examples of verifying JP1/AJS3 operations

The following table gives examples of verifying operations performed in JP1/AJS3.

Table C‒2: Examples of verifying JP1/AJS3 operations

Environment

Type of operation

Available information

Verification method

Development

Create or change a unit definition

--

--

Test

--

--

Export a unit definition to the production environment

Export result file of JP1/AJS3 - Definition Assistant

Determine the date and time of the unit definition from the name of the export result file of JP1/AJS3 - Definition Assistant.

Example:

The file name for a unit definition exported on 2009/12/20 13:43:25.976 would be:

ASJDA-EXPORT-091220134325976.xls

Production

Prepare to start system operation

Log entries about created units

List of last update times of unit definitions

The export file name of JP1/AJS3 - Definition Assistant is output to the requester ID information.

Compare the last update time of the unit definitions with the requester ID information in the log entries about created units to make sure no definitions were wrongly changed.

Register and execute a jobnet

Jobnet registration log entry

Jobnet execution log entry

Verify that the jobnet is correctly registered.

Verify that the jobnet has been correctly executed.

Rerun

Hold

Change plan

Operation log entries

From the output logs, make sure that the jobnet operation has been performed correctly.

Temporarily change a unit definition

Export result file of JP1/AJS3 - Definition Assistant

Log entry about the unit definition change

List of last update times of unit definitions

From the name of the export result file of JP1/AJS3 - Definition Assistant, determine the date and time of the unit definition after the change.

The file name of the export result file in JP1/AJS3 - Definition Assistant is output to the requester ID information.

Compare the last update time of the unit definition with the requester ID information in the log entry about the unit definition change to make sure the definition was not wrongly changed.

Legend:

--: None.

D. Communication Settings in Multiple-LAN Environments

This section explains connection examples for non-cluster and cluster operations for the multiple-LAN configurations described in 2.3.3 Connecting multiple LANs. Examples are provided according to which host on the LAN a product is used.

D.1 Example of connections and communication settings for non-cluster operation

The following explains connection examples for non-cluster operation in environments where multiple LANs are connected (dissociated network environments), and their communications settings. We deal in turn with cases where JP1/AJS3 - Manager and JP1/AJS3 - Agent are connected to multiple LANs.

(1) Cases where JP1/AJS3 - Manager is connected to multiple LANs for non-cluster operation

When JP1/AJS3 - Manager is connected to multiple LANs, JP1/AJS3 can be connected to JP1/AJS3 - Agent, JP1/AJS3 - View, or JP1/AJS3 - Manager on all the connected LANs. The hosts require an OS environment in which they can mutually resolve the host name.

(a) Case where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Agents

When JP1/AJS3 - Manager is connected to multiple LANs, jobs can be executed in the JP1/AJS3 - Agents on multiple LANs. The following figure shows an example when JP1/AJS3 - Manager is connected to multiple LANs to execute jobs in JP1/AJS3 - Agents on the LANs.

Figure D‒1: JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Agents)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs. JP1/AJS3 - Agent is installed on the host connected to each LAN.

In this system configuration, hostX serves as the manager host and jobs can be executed at the agent host host10 in the Management LAN, and the agent hosts hostA and hostB in the Work task LAN.

Regarding the communications settings at each host, follow the example communications settings for non-cluster operation in the JP1/Base User's Guide.

(b) Case where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Views

When JP1/AJS3 - Manager is connected to multiple LANs, units can be operated from JP1/AJS3 - Views on multiple LANs. The following figure shows an example when JP1/AJS3 - Manager is connected to multiple LANs to operate units from the JP1/AJS3 - Views.

Figure D‒2: JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Views)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs. JP1/AJS3 - View is installed on each host connected to each LAN.

In this system configuration, units at the manager host hostX can be operated from JP1/AJS3 - View at host10 on the Management LAN, and from JP1/AJS3 - Views at hostA and hostB on the Work task LAN.

Regarding the communications settings at host hostX, follow the example communications settings for non-cluster operation described in the JP1/Base User's Guide.

(c) Case where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Managers

When JP1/AJS3 - Manager is connected to multiple LANs, you can execute remote jobnets and remotely execute commands in the JP1/AJS3 - Managers on multiple LANs.

The following figure shows an example when JP1/AJS3 - Manager is connected to multiple LANs to execute remote jobnets on or remotely execute commands on JP1/AJS3 - Managers.

Figure D‒3: JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Managers)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs. JP1/AJS3 - Manager is installed on each host connected to each LAN.

In this system configuration, the manager host, hostX, is connected to the manager host host10 on the Management LAN, and to the manager hosts hostA and hostB on the Work task LAN. hostX executes remote jobnets and remotely executes commands.

Regarding the communications settings at the hosts host10, hostA, and hostB, follow the example communications settings for non-cluster operation described in the JP1/Base User's Guide.

(2) Case where JP1/AJS3 - Agent is connected to multiple LANs for executing jobs for non-cluster operation

When JP1/AJS3 - Agent is connected to multiple LANs, you can execute jobs from the JP1/AJS3 - Managers on all connected LANs. The hosts require an OS environment in which they can mutually resolve the host name.

The following figure shows an example when JP1/AJS3 - Agent is connected to multiple LANs to execute jobs from the JP1/AJS3 - Manager on each LAN.

Figure D‒4: JP1/AJS3 - Agent connected to multiple LANs (connection to JP1/AJS3 - Managers)

hostX, on which JP1/AJS3 - Agent is installed, is connected to multiple LANs. JP1/AJS3 - Manager is installed on each host connected to each LAN.

In this system configuration, hostX is the agent host. Jobs can be executed from the manager host host10 on the Management LAN and from the manager hosts hostA and hostB on the Work task LAN.

Regarding the communications settings at each host, follow the example communications settings for non-cluster operation described in the JP1/Base User's Guide.

(3) Cautionary note

When you specify IP binding as the receive setting for hostX on which JP1/AJS3 - Manager or JP1/AJS3 - Agent is installed, you need to specify both the IP address of the management LAN and the IP address of the work task LAN in jp1hosts or jp1hosts2 on hostX. If you do not, communication between hosts might not be performed as intended. For example, if only the IP address of the management LAN is written in jp1hosts or jp1hosts2 on hostX, communication from the work task LAN (hostA and hostB) to hostX might result in an error.

D.2 Example connections and communication settings for cluster operation

The following describes example connections and communications settings for cluster operation in an environment where multiple LANs are connected (dissociated network). The explanations deal separately with cases where JP1/AJS3 - Manager is connected to multiple LANs and cases where JP1/AJS3 - Agent is connected to multiple LANs.

(1) Cases where JP1/AJS3 - Manager is connected to multiple LANs in a cluster configuration

When JP1/AJS3 - Manager is connected to multiple LANs in a cluster configuration, you can connect JP1/AJS3 - Manager to JP1/AJS3 - Manager, JP1/AJS3 - Agent, or JP1/AJS3 - View on the LANs. The hosts require an OS environment in which they can mutually resolve the host name.

(a) Cluster system where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Agents

In a cluster system where JP1/AJS3 - Manager is connected to multiple LANs, you can link the JP1/AJS3 - Manager with JP1/AJS3 - Agents on the LANs. In this configuration, you can execute jobs with the JP1/AJS3 - Agents from either the physical or logical host. Such a system is shown below.

Figure D‒5: JP1/AJS3 - Manager connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Agents)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs for cluster operation. JP1/AJS3 - Agent is installed on each host connected to each LAN, and these hosts are defined as agent hosts for both the physical host hostX and the logical host hostL.

In this system configuration, hostX or hostL serves as the manager host and jobs can be executed at the agent host host10 on the Management LAN, and at the agent hosts hostA and hostB on the Work task LAN.

Regarding the communications settings at each host, follow the example communications settings for cluster operation in the JP1/Base User's Guide.

(b) Cluster system where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Views

When JP1/AJS3 - Manager is connected to multiple LANs for cluster operation, you might be able to use the JP1/AJS3 - Manager with JP1/AJS3 - Views on the LANs. When JP1/AJS3 - Manager is working with JP1/AJS3 - Views on the LANs, from the JP1/AJS3 - Views, you can operate units running on either the physical or logical host. Such a system is shown below.

Figure D‒6: Example of JP1/AJS3 - Manager connected to multiple LANs in a cluster system (connection with JP1/AJS3 - View)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs for cluster operation. JP1/AJS3 - View is installed on each host connected to each LAN.

In this system configuration, the physical host hostX or the logical host hostL serves as the manager host and units can be executed at the agent host host10 on the Management LAN, and at the agent hosts hostA and hostB on the Work task LAN.

Regarding the communications settings on each host, follow the example communications settings for cluster operation in the JP1/Base User's Guide.

Supplementary note

If a JP1/AJS3 - Manager service is not running (for example, if a physical JP1/AJS3 service is not used), you can connect JP1/AJS3 - View and JP1/AJS3 - Manager.

(c) Cluster system where JP1/AJS3 - Manager is connected to multiple LANs and linked to their JP1/AJS3 - Managers

When JP1/AJS3 - Manager is connected to multiple LANs and is linked to JP1/AJS3 - Managers on the LANs, you can execute remote jobnets and remotely execute commands on the physical or logical host from JP1/AJS3 - Managers on the LANs.

The following figure shows a connection example when JP1/AJS3 - Manager is connected to multiple LANs to execute remote jobs or remotely execute commands from JP1/AJS3 - Manager in a cluster configuration.

Figure D‒7: JP1/AJS3 - Manager connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Managers)

hostX, on which JP1/AJS3 - Manager is installed, is connected to multiple LANs for cluster operation. JP1/AJS3 - Manager is installed on each host connected to each LAN.

In this system configuration, the physical host, hostX, or the logical host, hostL, serves as the manager host. Remote jobnets can be executed, and commands remotely executed, either from the manager host host10 on the Management LAN or from the host hostA or hostB on the Work task LAN.

Regarding the communications settings at hostX, follow the example settings for cluster operation in the JP1/Base User's Guide.

Supplementary note

The rules for connecting JP1/AJS3 - Managers to execute remote jobnets or remotely execute commands are the same as the rules for connection from JP1/AJS3 - View.

(2) Cases where JP1/AJS3 - Agent is connected to multiple LANs to execute jobs in a cluster configuration

In a cluster system where JP1/AJS3 - Agent is connected to multiple LANs to work with JP1/AJS3 - Managers on the LANs, from the JP1/AJS3 - Managers, jobs can be executed on the physical or logical host. Such a system is shown below. The hosts require an OS environment in which they can mutually resolve the host name.

Figure D‒8: JP1/AJS3 - Agent connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Managers)

hostX, on which JP1/AJS3 - Agent is installed, is connected to multiple LANs for cluster operation. JP1/AJS3 - Manager is installed on each host connected to each LAN, and both the physical host hostX and the logical host hostL are defined as agent hosts.

In this system configuration, the physical host hostX, or the logical host hostL, serves as the agent host. Jobs can be executed either from the manager host host10 on the Management LAN or the manager host hostA or hostB on the Work task LAN.

Regarding the communications settings at each host, follow the example settings for cluster operation in the JP1/Base User's Guide.

(3) Cautionary notes

For JP1/AJS3 - Manager and JP1/AJS3 - Agent in a cluster configuration, the IP binding method must be set for the receive setting. The reason is that if the ANY binding method is set, data sent to a physical host might be received by a logical host, or data sent to a logical host is received by a physical host. Either case prevents jobs from being executed normally.

Because the receive setting is set to the IP binding method immediately after a cluster is set up, data can be received from only one LAN even if multiple LANs are connected. Therefore, you need to set up the JP1/Base communication protocol as described in the example of setting up communication for a cluster system in the JP1/Base User's Guide.

Because the transmission setting is set to the IP binding method immediately after a cluster is set up, the data can be sent to only one LAN, and the host on either LAN can be linked. Therefore, to connect to multiple LANs, you need to set the transmission setting to the ANY binding method. For details, see the example of setting up communication for a cluster system in the JP1/Base User's Guide.

When connection is established from JP1/AJS3 - View to JP1/AJS3 - Manager, the host that matches the IP address specified in the connection setting is connected, no matter whether the host is a physical or logical host.

D.3 JP1/AJS3 - View communication settings

The following describes example connections and communications settings when JP1/AJS3 - View is used in an environment where multiple LANs are connected (dissociated network).

(1) Case where JP1/AJS3 - View is connected to multiple LANs to operate units

When JP1/AJS3 - View is connected to multiple LANs, you can operate units from the JP1/AJS3 - Managers on all connected LANs.

The following figure shows an example when JP1/AJS3 - View is connected to multiple LANs to operate units from JP1/AJS3 - Managers.

Figure D‒9: JP1/AJS3 - View connected to multiple LANs (connection to JP1/AJS3 - Managers)

hostX, on which JP1/AJS3 - View is installed, is connected to multiple LANs. JP1/AJS3 - Manager is installed on each host connected to each LAN.

In this system configuration, JP1/AJS3 - View on hostX can connect to the manager host host10 on the Management LAN, and to the manager hosts hostA and hostB on the Work task LAN to operate units.

Regarding the communications settings at host10, hostA, and hostB, follow the example communications settings for non-cluster operation described in the JP1/Base User's Guide.

Note that hostX requires an OS environment capable of resolving the host names of host10, hostA, and hostB to IP addresses. Because JP1/AJS3 - View does not apply the settings in the jp1hosts file or the jp1hosts2 file, set the hosts file or DNS server so that the host names can be resolved.

E. Operating JP1/AJS3 By Using an AJS Administrator Account (UNIX Only)

This appendix describes the conditions for, and cautionary notes on, operating JP1/AJS3 by using an AJS administrator account. For an overview of AJS administrator accounts, see 7.1.3 User management using the JP1 administrators group of JP1/Base (UNIX only) in the manual JP1/Automatic Job Management System 3 Overview.

For details about how to set an AJS administrator account, see D. Installation and Setup for Operation by AJS Administrators (UNIX only) in the JP1/Automatic Job Management System 3 Configuration Guide.

E.1 Operating JP1/AJS3 by using an AJS administrator account

An AJS administrator can manage and operate a JP1/AJS3 system except for some operations that require superuser privileges. When you set an AJS administrator account, the AJS administrator and a user with superuser privileges (system administrator) can divide the workload of managing and operating a JP1/AJS3 system.

For example, the AJS administrator could specify the environment settings of JP1/AJS3 and perform daily operations while the system administrator performed only the operations, such as installations, that require superuser privileges.

The following figure shows an example in which the AJS administrator and the system administrator divide the workload of creating and operating a JP1/AJS3 system.

Figure E‒1: Example of dividing the workload of creating and operating a JP1/AJS3 system

In this example, the AJS administrator and the system administrator divide the workload as follows.

Creating the system

The AJS administrator asks the system administrator to install programs such as JP1/AJS3 and JP1/Base and to allocate OS resources. The system administrator installs the programs and allocates OS resources as requested. When the system administrator's work is finished, the AJS administrator sets up JP1/AJS3. For a cluster system, the AJS administrator asks a user who has the operation privilege for cluster software such as the system administrator to operate the cluster software.

Operating the system

The AJS administrator performs daily operations. When necessary, the AJS administrator starts and stops JP1/AJS3, backs up definitions, and maintains the database. If the AJS administrator does not have the operation privilege for cluster software, the AJS administrator asks the system administrator or any other user with the operation privilege to operate the cluster system.

If a problem occurs, the system administrator collects the data necessary for determining the cause of the problem.

E.2 Conditions for setting an AJS administrator account

All of the following conditions must be satisfied to set up an AJS administrator account. Make sure beforehand that all of these conditions can be satisfied in the environment where the JP1/AJS3 system is to be created.

Initial installation of JP1/AJS3

An AJS administrator account can be set up when JP1/AJS3 is initially installed. No AJS administrator account can be set up in an environment where JP1/AJS3 is already installed.

Note that you cannot set up an AJS administrator account when you perform an upgrade installation. If you want to set up an AJS administrator account when you upgrade JP1/AJS3, back up the definitions of JP1/AJS3 currently in use, uninstall JP1/AJS3, and re-install JP1/AJS3.

Operation of JP1/AJS3 by using an AJS administrator account does not violate security policies

An AJS administrator can control JP1/AJS3 processes that are executed with superuser privileges. If there are security policy issues when an ordinary OS user is able to control processes executed with superuser privileges, you must not set an AJS administrator account.

A dedicated OS user can be prepared for the AJS administrator account

If you set an OS user as an AJS administrator, you cannot change the setting later. For this reason, prepare a dedicated OS user for the AJS administrator account so that the AJS administrator account does not need to be changed during operation.

If you set an OS user assigned solely to an individual for the AJS administrator account, problems arise if the individual is transferred somewhere else. Do not set an OS user assigned solely to an individual for the AJS administrator account.

E.3 Cautionary notes on using an AJS administrator account

An AJS administrator can control the processes that are executed with superuser privileges. Manage the AJS administrator account very carefully, treating it as if it were the superuser account (root user).

During JP1/AJS3 operations, do not delete the JP1 administrators group or AJS administrator account. If you accidentally delete the JP1 administrators group, create it again and restart the JP1/AJS3 service. The following settings of the JP1 administrators group that you create must be the same as those of the original JP1 administrators group that you deleted:

Name of the OS user group for the JP1 administrators group

Group ID of the OS user group for the JP1 administrators group

If you accidentally delete the AJS administrator account, create it again and restart the JP1/AJS3 service. The following settings of the AJS administrator account that you create must be the same as those of the AJS administrator that was specified when JP1/AJS3 was installed:

OS user name for the AJS administrator

User ID of the OS user for the AJS administrator

Primary group of the OS user for the AJS administrator

Note that you can use the jajsshowadminusr command to check the information for the JP1 administrators group and AJS administrator account that were specified during the JP1/AJS3 installation. For details about the jajsshowadminusr command, see jajsshowadminusr (UNIX only) in 3. Commands Used for Normal Operations in the JP1/Automatic Job Management System 3 Command Reference.

F. Handling database errors

Consider what backup and recovery methods to use if an error occurs in the database used by JP1/AJS3.

F.1 Overview of database backups

You can back up all the tables in a JP1/AJS3 database (embedded database) to a file in case a failure occurs. If an error occurs in the scheduler database, the backup file can be used to restore the database to its state at the time the backup was taken.

When the embedded database is used, JP1/AJS3 creates system log files containing historical information about updates to the scheduler database. Using the database backup file and the information logged to these system log files, you can restore the scheduler database to its most recent state.

Creating backup files and restoring the database differ according to how the JP1/AJS3 system is operated. The following backup and recovery methods can be used:

Operation by using the backup enhancement function

The backup enhancement function backs up the data of an embedded database at one time during operation, and recovers the status when the backup was created without requiring cold start.

If you enable the backup enhancement function when setting up an embedded database, you can use the jajs_dbbackup command to back up the data of the embedded database during operation. The database can be restored at one time from the backup data by using the jajs_dbrestore command.

Method 1: Using unload log files

The embedded database automatically unloads the system logs. These unloaded files are known as unload log files.

In method 1, the database is restored from unload log files in addition to the backup taken at regular intervals.

This method restores the scheduler database, not just to its state at the time the backup file was created, but instead to the latest information since the backup was taken.

For details, see (1) Restoring the scheduler database from unload log files.

Method 2: Without using the system log

In method 2, the database is restored from backup files only, without using system log files or unload log files. This is simplest method, as the system log is not involved.

With this method, however, you cannot restore the latest information since the backup files were created. For details, see (2) Restoring the scheduler database without using the system log.

For more information about the two backup and restore methods, see 23.1.1 Examining the embedded-database operating environment and operating method in the JP1/Automatic Job Management System 3 Configuration Guide.

For an overview of the backup enhancement function, see 5.2.1(5) Backing up and restoring an embedded database.

This section describes the operation that uses unload log files and operation that does not use the system log.

(1) Restoring the scheduler database from unload log files

The following describes how to restore the scheduler database using the unload log files created automatically by the embedded database in addition to the database backup file.

The following figure shows how to recover from a database error using unload log files.

Figure F‒1: Recovery after an error (using unload log files)

(a) Duplicating the system files

In a configuration where the system files used by the embedded database are not duplicated, the embedded database stops when an error occurs in a system file.

If the system files are duplicated, and a disk error or other problem occurs in one set of system files, the system files can be restored the moment the error occurs and in the state they are in right before the error occurs. Note that file duplication requires more disk space than for unduplicated system files.

(b) Using unload log files

Automatic log unload function

The embedded database swaps the system log file to an alternate system log file at the following times:

When the current system log file is full

When the ajsembdbbackup command is executed

When the ajsembdboplog command is executed with the -w option specified

When the embedded database is restarted (only if it was stopped normally during the previous run)

When the current system log file is swapped out, it waits to be unloaded#1 and cannot be re-assigned. To make this system log file available again, it must be unloaded.#2 The embedded database automatically unloads the waiting system log files to a specified directory. The unloaded files are called unload log files, and the function that unloads them is called the automatic log unload function. These unload log files are used in addition to the database backup file to restore the database after a failure.

#1

In this state, the system log file contains historical update information, which is needed for a recovery, and cannot be overwritten. The file cannot be swapped in as an alternate system log file. It must be unloaded first.

#2

Unload here means to back up the data in the system log file.

Unload log file size

The size of the unload log files depends on the scale you set when configuring the environment for the embedded database. The table below lists the size of one unload log file for each of the specifiable scales. Refer to the values in the table when estimating the disk space required for unload log files.

Table F‒1: Size of an output unload log file

Scale specified when configuring the environment for the embedded database

Size of one unload log file

Large scale

Approx. 1,200 megabytes

Medium scale

Approx. 230 megabytes

Small scale

Approx. 30 megabytes

If you have increased the maximum size of a system log file using the ajsembdbaddlog command, compare the size specified in the -s option of the command with the size shown in Table F-1. The larger of the two values will be the maximum size of an unload log file. If you have increased the system log file size using the function for automatically expanding the system log, the maximum size of an unload log file will be three times the size given in Table F-1.

In either case, use the larger value to estimate the disk space required for unload log files.

Note that the size of an unload log file could vary depending on the output timing.

Estimating when the disk containing the unload log directory will become full

Unless they are deleted or moved to another disk, unload log files continue to be created in the same directory. The number of files keeps growing as JP1/AJS3 continues running, eventually filling the disk in which the unload log directory resides. When the disk is full, the automatic log unload function stops, resulting in Issue caused by the automatic log unload function stopping described below.

For this reason, you need to estimate when the disk is likely to become full. Back up the embedded database before that point, and delete unload log files created before the backup was taken or move them to another disk. If backing up the database before the disk is full is not feasible, temporarily move the unload log files to another disk to free up space on the disk containing the unload log directory. For details about how to delete or move unload log files, see B.2(3) Managing backup files and unload log files in the JP1/Automatic Job Management System 3 Administration Guide.

The rest of this subsection describes how to estimate at what point the disk with the unload log directory is likely to become full.

The following table provides guidance on how much information can be output to one system log file.

Table F‒2: Maximum amount of information output to one system log file

Scale specified when configuring the environment for the embedded database

Number of jobs or jobnets executed per day

Large scale

Approx. 50,000

Medium scale

Approx. 9,600

Small scale

Approx. 1,200

Note

These values vary depending on the operations that are performed on jobs and jobnets, and how often units are created, redefined, deleted, and so on. Adjust the estimated value according to your system operation.

Using the values in the above table and the size of one unload log file as listed in Table F-1, you can estimate how many days it will take for the disk to become full from the time operation starts.

An estimation example is shown below:

Conditions:

Scale of the embedded-database environment: Large

Disk space required for the unload log directory: 10 gigabytes

Calculation:

10 gigabytes / 1,200 megabytes = 8 days

Under these conditions, you can predict that the disk will be full, at the earliest, at the end of operation on the 8th day from the start of operation.

Issue caused by the automatic log unload function stopping

When the automatic log unload function stops, the embedded database no longer unloads system log files. If files are not unloaded, the number of system log files waiting to be unloaded continues to increase. If there is no system log file available when the current system log file is ready to be swapped out, the embedded database terminates abnormally.

For details about what causes the automatic log unload function to stop, see Table F-3.

Monitoring the operating status of the automatic log unload function

If the automatic log unload function stops, Issue caused by the automatic log unload function stopping described above occurs. The operating status of the automatic log unload function therefore needs to be monitored at regular intervals.

You can use either of the following two methods to monitor whether the function is active:

Monitoring using a message

If the automatic log unload function stops, message KFPS01150-E is output to the Windows event log or to syslog in UNIX. Determine whether the automatic log unload function is active according to whether this message appears.

Monitoring using a command

You can check whether the automatic log unload function is active by executing the ajsembdboplog command with the -s option specified, as in the following example. Here, the environment for the embedded database whose ID is _JF0 has already been set up:

ajsembdboplog -s -id _JF0

HOSTNAME : host_name (180252)
SERVER_NAME:ajs2
AUTO_LOG_UNLOAD  NOW_UNLOAD_LOG_GROUP  CREATE_DIR
          ACTIVE                    ****  K:/logback
CURRENT LOG GENERATION INFO.
LOG_GROUP GEN_NO.  SERVER_RUN_ID RUN_ID   UNLOAD_FILE_NAME
     log1        1   43c4ad0d      43c4acf3 ajs2_43c4ad0d0001_log1

In the execution result, the string (underlined portion) shown for AUTO_LOG_UNLOAD indicates the operating status of the automatic log unload function. The function is active if ACTIVE appears, but has stopped if STOP appears.

If you find that the automatic log unload function has stopped, take the action described in Table F-3, and then execute the ajsembdboplog command with the -r option specified, as in the following example:

ajsembdboplog -r -id _JF0

This command restarts the automatic log unload function.

Reasons for the automatic log unload function to stop

The following table lists the reasons why the automatic log unload function might stop, and describes what action to take in each case.

Table F‒3: Reasons for the automatic log unload function to stop, and corrective actions

Reason

Action

An error occurred on the disk that contains the unload log directory.

Back up the embedded database in case the unload log files are lost. After correcting the disk error, execute the ajsembdboplog command with the -r option specified, as follows:

ajsembdboplog -r

This command restarts the automatic log unload function.

The disk that contains the unload log directory is full.

For details about what action to take when the disk is full, see B.2(3) Managing backup files and unload log files in the JP1/Automatic Job Management System 3 Administration Guide. After taking the indicated action, execute the ajsembdboplog command with the -r option specified, as follows:

ajsembdboplog -r

This command restarts the automatic log unload function.

The unload log directory is unavailable for either of the following reasons:

Incorrect permissions are set.

No such directory exists.

After removing the cause of the error, execute the ajsembdboplog command with the -r option specified, as follows:

ajsembdboplog -r

This command restarts the automatic log unload function.

The ajsembdboplog command was executed with the -t option specified.

Execute the ajsembdboplog command with the -r option specified, as follows:

ajsembdboplog -r

This command restarts the automatic log unload function.

Recovery when the embedded database terminates abnormally because there is no alternate system log file

If the embedded database terminates abnormally because there is no system log file to swap in, take the following steps:

Stop the scheduler service and all other services that access the database.

Unload the system log.

Execute the ajsembdboplog command to unload the system log file that is waiting to be unloaded. For the output size per file, see Table F-1.

Start the embedded database.

Execute the ajsembdbstart command to start the embedded database. The format of the command differs in Windows and UNIX, and according to the status of the embedded database.

In Windows:

Execute the ajsembdbstart command without specifying any options other than the -id option.

In UNIX:

The format of the ajsembdbstart command depends on the status of the embedded database. To check the database status, execute the ajsembdbstatus command. In the following execution example, the environment for the embedded database whose ID is _JF0 has already been set up:

ajsembdbstatus -s ust -id _JF0

HOSTNAME : host_name(144852)

SYSTEMID : ajs2

UNITID : unt1

ENTRYHOST : host_name

PAIRHOST :

UNIT-STAT FES-STAT SETUP-STAT

STOP ******** SETUP

In the execution result, the string (underlined portion) shown for UNIT-STAT indicates the status of the embedded database. How you execute the ajsembdbstart command is determined by this information. If UNIT-STAT is STOP, execute the ajsembdbstart command with only the -id option specified. If UNIT-STAT is PAUSE, execute the ajsembdbstart command with the -id and -R options specified.

Start the services that you stopped at step 1.

Hot-start or warm-start the JP1/AJS3 services. Before you do so, check whether the status of the scheduler database is consistent with the actual job execution status. As the status of the scheduler database can only be preserved until just before the embedded database terminated abnormally, there might be inconsistencies with other control information. If it is too difficult to determine whether the scheduler database is consistent with the actual job execution status, cold-start the JP1/AJS3 services and register the jobnets for execution.

(c) Cautionary notes

Note the following points when using unload logs.

When configuring the environment

Duplication of system files requires more disk space than for unduplicated system files. For the amount of disk space required, see 23.1 Preparation for using an embedded database in the JP1/Automatic Job Management System 3 Configuration Guide.

Unload log files cannot be used together with the backup enhancement function. For an overview of the backup enhancement function, see 5.2.5 Backing up and recovering an embedded database by using the backup enhancement function.

When using unload logs

Unless they are deleted or moved to another disk, unload log files continue to be created in the same directory. The number of files keeps growing as JP1/AJS3 continues running, putting pressure on the disk that contains the unload log directory. Once you back up the database, you can delete unload log files created prior to the time at which you took the backup. For details about how to delete or move unload log files, see B.2(3) Managing backup files and unload log files in the JP1/Automatic Job Management System 3 Administration Guide.

When the automatic log unload function stops, the embedded database no longer unloads system log files, so the number of system log files waiting to be unloaded continues to increase. If there is no system log file available when the current system log file is ready to be swapped out, the embedded database terminates abnormally. You must therefore monitor whether the automatic log unload function is active. For the procedure, see Monitoring the operating status of the automatic log unload function in (b) Using unload log files.

If you take backup while the JP1/AJS3 service is active, conflict between the ajsembdbbackup command and the job execution process will result in degraded performance in both processes. Take backup at a time when the least amount of jobs are being executed.

When restoring the database

If the scheduler database is backed up while the JP1/AJS3 service is active, in addition to the backup file, you will require unload log files output since the backup was taken to perform a restoration. If the unload log files have been deleted, back up the database again because you will not be able to restore it using only the backup file created while the JP1/AJS3 service was active.

When restoring the scheduler database using unload log files, you will need all the unload log files output since the backup was taken (that is, all those created since the ajsembdbbackup command was executed).

When restoring the scheduler database using unload log files, we recommend that you specify the -ld option in the ajsembdbrstr command. If you use the -l option, you must specify in date order all the unload log files needed to restore the database, starting from the oldest. If you specify the files in the wrong order or miss any file, the ajsembdbrstr command terminates with an error. For the command syntax, see ajsembdbrstr in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(2) Restoring the scheduler database without using the system log

The following describes how to restore the scheduler database from a backup file only, without using any system log files. This is the simplest method, requiring no unload log files. The following figure shows how to recover from a database error without using the system log.

Figure F‒2: Recovery after an error (without using the system log)

With this method, you do not need to monitor the system log files. However, as the system log is not used at recovery, any updates since the backup file was created cannot be restored.

(a) Cautionary notes

Note the following points when not using the system log at recovery.

When configuring the environment

Since the system log is not used, the database cannot be restored from system log files. However, because it is used by the embedded database, sufficient disk space must still be allocated to store the system log. For the required disk space, see 23.1 Preparation for using an embedded database in the JP1/Automatic Job Management System 3 Configuration Guide.

When backing up the database

The scheduler database cannot be backed up to a file while JP1/AJS3 services are active. Take backup at a time when the JP1/AJS3 services can be stopped. For details about how to back up the scheduler database, see B.1(3) Procedure for creating a backup file in the JP1/Automatic Job Management System 3 Administration Guide.

When restoring the database

If an error occurs, the scheduler database cannot be restored to its state immediately before the error. Because the system log is not used, the database can only be restored to the point in time at which the backup was taken. For the recovery procedure, see B.1(4) Procedures for restoring the database if an error occurs in the JP1/Automatic Job Management System 3 Administration Guide.

G. Using JP1/AJS3 - Agent Minimal Edition

This appendix describes the job operation using JP1/AJS3 - Agent Minimal Edition.

G.1 Purpose of JP1/AJS3 - Agent Minimal Edition

JP1/AJS3 - Agent Minimal Edition is suitable for installation on computers that need to execute about five jobs per day, such as starting and stopping services, performing daily backups, and collecting logs. This product has the same functionality as JP1/AJS3 - Agent, except for some functions that are restricted.

The following figure shows an example of a system configuration that uses JP1/AJS3 - Agent Minimal Edition.

Figure G‒1: Example of a system configuration using JP1/AJS3 - Agent Minimal Edition

JP1/AJS3 - Agent Minimal Edition has the following differences in functionality from JP1/AJS3 - Agent:

JP1/AJS3 - Agent Minimal Edition can execute a maximum of 10 jobs a day.#1, #2

JP1/AJS3 - Agent Minimal Edition enables the number of jobs executed per day to be checked via the agent host.

JP1/AJS3 - Agent Minimal Edition cannot execute custom, flexible and queueless jobs.

#1

Execution of the following types of jobs is subject to limitation. Note that there is no limitation on the number of times event jobs can be executed.

Standard Job

Action Job

Submit Job

HTTP Connection Job

#2

The maximum number of jobs that can be executed per day is 10. Any subsequent jobs will be placed in Failed to start status and will not be executed.

Cautionary note

The maximum number of jobs that can be executed, the types of jobs that can be executed, and other operational considerations related to JP1/AJS3 - Agent Minimal Edition functions are described here. If JP1/AJS3 - Agent Minimal Edition does not meet your operational requirements, use JP1/AJS3 - Agent.

G.2 Points to be checked before installing JP1/AJS3 - Agent Minimal Edition

This section describes the points to be checked before installing JP1/AJS3 - Agent Minimal Edition.

The operating environment and prerequisites for JP1/AJS3 - Agent Minimal Edition are almost the same as those for JP1/AJS3 - Agent.

The following describes the differences between JP1/AJS3 - Agent Minimal Edition and JP1/AJS3 - Agent.

(1) Prerequisite operating systems

For details about OSs that are supported for JP1/AJS3 - Agent Minimal Edition, see 2.1.2(1) Prerequisite operating systems.

(2) Version compatibility

To use JP1/AJS3 - Agent Minimal Edition, you must consider the compatibility among the versions of the following: JP1/Base (which is a prerequisite product for JP1/AJS3), and JP1/AJS3 - Manager.

(a) Version compatibility between JP1/Base and JP1/AJS3 - Agent Minimal Edition

For details about version compatibility between JP1/Base and JP1/AJS3 - Agent Minimal Edition, see 8.1.1 Version compatibility between JP1/Base and JP1/AJS3.

(b) Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent Minimal Edition

For details about version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent Minimal Edition, see 8.1.3 Version compatibility between JP1/AJS3 - Manager and JP1/AJS3 - Agent.

(3) Estimating the job execution history log file

JP1/AJS3 - Agent Minimal Edition outputs a history of executed jobs to the job execution history file, or a log file dedicated to executed jobs.

(a) About the job execution history log file

The job execution history log file is generated in the computer on which JP1/AJS3 - Agent Minimal Edition is installed. If multiple agent hosts (physical and logical hosts) exist on the same computer, the history of jobs executed by all the hosts is output to the same job execution history log file.

The default settings of the job execution history log file are as follows:

Storage location

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

In Windows, if the installation folder is other than the above:

JP1/AJS3-Agent-Minimal-Edition-installation-folder\log

In Linux:

/var/opt/jp1ajs2/log

Size

512 kilobytes

Number

2

(b) Estimating the size of the job execution history log file

The required size of a job execution history log file and the required number of job execution history log files vary depending on how the log file is operated. Estimate the appropriate size of the job execution history log file, and change its size and the number of files as needed.

Use the following formula to estimate the size of a job execution history log file:

Appropriate the job execution history log file capacity (units: kilobytes) = 3# x number-of-days-to-save-logs

#

3 (kilobytes) is the value obtained by multiplying 0.3 (approximate size of the log data output per job) by 10 (number of job executions).

To more accurately estimate the size of log data output per day, calculate the size of the log output per job by the following formula, and multiply the calculation result by the number of job executions per day.

Size of the log data output per job (units: kilobytes) = 0.135 + unit-full-name-length + manager-host-name-length

Example:

If 10 jobs are to be executed per day and the logs for 365 days are to be saved, the appropriate capacity of the job execution history log file is as follows:

0.3 x 10 x 365 = 1,095 kilobytes

You can specify the size of a job execution history log file and the number of job execution history log files by using the environment setting parameters listed in the following table.

Table G‒1: Environment setting parameters to change the size of a job execution history log file

No.

Environment setting parameter

Description

Relevant section

1

JobHistoryLogFileSize

Size of a job execution history log file

20.5.2(94) JobHistoryLogFileSize in the JP1/Automatic Job Management System 3 Configuration Guide

2

JobHistoryLogFileCount

Number of the job execution history log files

20.5.2(95) JobHistoryLogFileCount in the JP1/Automatic Job Management System 3 Configuration Guide

(c) Changing the size of a job execution history log file or the number of job execution history log files

To change the size of a job execution history log file or the number of job execution history log files, you must delete any existing job execution history log files and the management file for them before changing the value of relevant environment setting parameter. If you do not delete the existing job execution history log files and management file, the new size of a job execution history log file or the new number of job execution history log files will not be applied.

To change the size of a job execution history log file or the number of job execution history log files:

Stop the JP1/AJS3 services on the physical host and all logical hosts running on the computer where the job execution history log files exist.

Back up the job execution history log files (jpqjobhistory{0|1}.log) as needed.

For details on the location of the job execution history log file, see (a) About the job execution history log file.

Delete all job execution history log files.

Delete the management file for the job execution history log file (jpqjobhistory.mm).

The management file for the job execution history log file is stored in the mmap folder under the storage directory for the job execution history log files.

For details on the location of the job execution history log file, see (a) About the job execution history log file.

Change the value of the JobHistoryLogFileSize or JobHistoryLogFileCount environment setting parameter.

Start the JP1/AJS3 service stopped in step 1.

(4) Computer on which JP1/AJS3 - Agent Minimal Edition is installed

You cannot install JP1/AJS3 - Manager, JP1/AJS3 - Agent and JP1/AJS3 - Agent Minimal Edition on the same computer.

G.3 Counting the number of executed jobs

This section describes how to count and check the number of jobs executed in a day by JP1/AJS3 - Agent Minimal Edition.

(1) Counting the number of executed jobs

JP1/AJS3 - Agent Minimal Edition manages the number of jobs that are executed. When JP1/AJS3 - Agent Minimal Edition receives a job execution request from the manager host, that job is added to the number of executed jobs.

Assume that you want to re-execute or automatically retry a job by JP1/AJS3 - Agent Minimal Edition. In such a case, re-execute or automatically retry the job within 48 hours after the KAVU3607-I message that includes the execution ID of the job was output to the job execution history log file.However, if a job is re-executed or automatically retried 48 hours or more after the original request, the job is counted as one of the 10 jobs executed for the day on which it is re-executed or automatically retried. Note that the addition of this job reduces the maximum number of remaining jobs that can be executed on that day. As a result, jobs that were scheduled to be executed on that day might not be executed. If it is likely that jobs will not be re-executed or automatically retried within 48 hours, we recommend that you use JP1/AJS3 - Agent to avoid this problem.

Supplementary notes

JP1/AJS3 - Agent Minimal Edition manages the number of executed jobs by using the following information included in the job execution requests received from JP1/AJS3 - Manager:

- Manager host name

- Scheduler service name

- Job name

- Execution ID

A re-executed or automatically retried job will not be added to the current day's number of executed jobs if the job's information, as described in the preceding list, matches a job that was executed in the previous 48 hours. However, if 48 hours or more have passed since the message KAVU3607-I was output to the job execution history log file, the job will be added to the number of jobs executed that day.

The execution ID of a job does not change if the job is re-executed or automatically retried. However, the execution ID of a job executed by JP1/AJS3 - Agent Minimal Edition changes if a jobnet that contains the job is registered for immediate execution. In addition, the execution ID changes if a jobnet that contains the job is re-registered for execution after its registration is canceled, or after the manager host is cold-started. When a job is executed with a different execution ID, the job will be added to the number of jobs executed that day. In the event of system-wide recovery or recovery from a system failure, you might need to cold-start the manager host. We recommend, therefore, that you create an operational plan for JP1/AJS3 - Agent Minimal Edition so that no more than five jobs are executed per day.

JP1/AJS3 - Agent Minimal Edition differs from JP1/AJS3 - Agent in that you must take into account the number of executed jobs when you register jobs for execution, or when you cancel registration. For jobs that are registered for execution (or for which registration is canceled), we recommend that you create a root jobnet for each job that is to be executed by using JP1/AJS3 - Agent Minimal Edition to distinguish such jobs from other jobs.

If you use JP1/AJS3 - Agent Minimal Edition to execute a job multiple times for test purposes, re-execute the job rather than repeatedly registering the job for immediate execution with JP1/AJS3 - Manager. If you repeatedly register the job for execution, JP1/AJS3 - Agent Minimal Edition adds each execution of the job to the number of jobs executed that day.

The number of jobs executed per day is counted per computer. If multiple agent hosts (physical and logical hosts) exist on the same computer, the jobs executed by individual agent hosts are tallied, and a maximum of 10 jobs can be executed.

The following figure shows how to count the number of executed jobs when multiple agent hosts exist on the same computer.

Figure G‒2: Counting the number of executed jobs when multiple agent hosts exist on the same computer

The number of executed jobs is reset every day at 00:00 o'clock in the time zone set on the computer where JP1/AJS3 - Agent Minimal Edition is installed. The number of executed jobs is always reset at 00:00 o'clock, even if a local date and time is set for the scheduler service by JP1/AJS3 - Manager. Even if the number of jobs executed in a day is less than 10, the remaining number of jobs that can be executed in the day is not carried over to the next day.

Note, however, that event jobs can be executed without limitation on the number executed.

If JP1/AJS3 - Agent Minimal Edition uses the connection source restriction function, it can reject job execution requests from the manager hosts that are not permitted to connect to JP1/AJS3 - Agent Minimal Edition. In that case, the number of executed jobs is not incremented even when such a manager host issues a job execution request.

(2) Checking the number of executed jobs

You can check the number of jobs executed by JP1/AJS3 - Agent Minimal Edition in a day on the agent host where JP1/AJS3 - Agent Minimal Edition is running.

To check the number of jobs executed in a day from the agent host:

Open the job execution history log file (jpqjobhistory{0|1}.log).

The job execution history log file storage directories are as follows:

In Windows, if the installation folder is the default installation folder or is in a folder protected by the system:

%ALLUSERSPROFILE%\Hitachi\JP1\JP1_DEFAULT\JP1AJS2\log

The default %ALLUSERSPROFILE% value is system-drive\ProgramData.

A folder protected by the system is the path to a folder in any of the following:

- system-drive\Windows

- system-drive\Program Files

- system-drive\Program Files (x86)

In Windows, if the installation folder is other than the above:

JP1/AJS3-Agent-Minimal-Edition-installation-folder\log

In Linux:

/var/opt/jp1ajs2/log

Among the KAVU3607-I messages output to the job execution history log file, find the message that was output last with the date for which you want to check the number of executed jobs.

Check the number of executed jobs indicated in the found message.

Cautionary notes

When log records in a job execution history log file are wrapped around to the next file, the original file is not deleted but is overwritten with new log records from the top of the file. To distinguish between log records output before and after wrapping around, the following character string (endpoint identifier) is output at the end of the latest log record.

----------< End of Data >----------

Each time a job is executed, the endpoint identifier at the end of the preceding log data is deleted, new log data is output, and then the endpoint identifier is output at the end of the new log data. Therefore, note the following points when referencing a job execution history log file:

To check the latest log data, reference the log data preceding the endpoint identifier. The log data that follows the endpoint identifier is the log records output before wrapping around.

If the log records in a job execution history log file have been wrapped around in special timing, two or more endpoint identifiers might remain in the job execution history log file. In such a case, the first endpoint identifier counted from the top of the file is valid.

(3) After the number of jobs executed in a day has reached 10

If an attempt is made to execute a job after the number of jobs executed by JP1/AJS3 - Agent Minimal Edition in a day has reached 10, the eleventh job ends in Failed to start status. Then, the KAVU3608-E message is output to the integrated trace log and job execution history log file on the computer where JP1/AJS3 - Agent Minimal Edition is running. The same message is also output in the Execution Result Details window of JP1/AJS3 - View.

If a job executed by JP1/AJS3 - Agent Minimal Edition ends in Failed to start status and the KAVU3608-E message is output, review system operations so that the number of jobs executed per day will not exceed 10.

If a transfer file has been specified in the job definition for the job executed as the eleventh or subsequent job, the job ends in Failed to start status, but the file is transferred to the destination agent host. If you want to delete that file, in the Define Details dialog box, select the Transfer File tab, and then select the Yes check box.

G.4 Cautionary notes on using JP1/AJS3 - Agent Minimal Edition

This section describes points to note when using JP1/AJS3 - Agent Minimal Edition.

(1) Installing JP1/AJS3 - Agent Minimal Edition in an overwrite installation

If you install JP1/AJS3 - Agent Minimal Edition in an overwrite installation or upgrade installation, the number of executed jobs is not inherited.

(2) Change of the system time

Changing the system time on a computer where JP1/AJS3 - Agent Minimal Edition is running can affect the number of jobs executed per day. If you change the system time, note the following points:

Before changing the system time, make sure that there is no job that needs to be re-executed. If the system time is changed, the number of executed jobs might be incremented even when a job is re-executed within 48 hours after the KAVU3607-I message was output to the job execution history log file.

If you turn back the system time by a period that spans dates, the number of jobs that can be executed in the current day might be reduced from the maximum number of jobs set before the change of the system time.

(3) Cautionary notes on disaster recovery operation

The following describes points to note when using JP1/AJS3 - Agent Minimal Edition in the disaster recovery mode.

For details about the disaster recovery operation, see 11. Disaster Recovery in JP1/AJS3 in the JP1/Automatic Job Management System 3 Administration Guide.

JP1/AJS3 - Agent Minimal Edition manages the number of executed jobs for each computer where an agent host is installed. Therefore, how to count the number of executed jobs after switching over operation to a remote site differs depending on whether the agent host is shared by the main site and a remote site.

(a) In the case of unshared agent type

In a system configuration of unshared agent type, the number of executed jobs is not inherited when operation is switched over from the main site to a remote site. At the remote site to which operation was switched over, a maximum of 10 jobs can be executed per day.

The following figure shows an example of switching over operation to a remote site in a system configuration of unshared agent type.

Figure G‒3: Switching over operation to a remote site in a system configuration of unshared agent type

If, after a job has been executed at the main site, operation is switched over to a remote site, and then the job is re-executed at the remote site, the number of executed jobs is incremented.

(b) In the case of shared agent type

In a system configuration of shared agent type, the number of executed jobs is inherited when operation is switched over from the main site to a remote site.

The following figure shows an example of switching over operation to a remote site in a system configuration of shared agent type.

Figure G‒4: Switching over operation to a remote site in a system configuration of shared agent type

Assume that the logical host name of JP1/AJS3 - Manager is different between the main site and remote site. In such a case, if, after a job has been executed at the main site, operation is switched over to a remote site, and then the job is re-executed at the remote site, the number of executed jobs is incremented.

G.5 Migrating from JP1/AJS3 - Agent Minimal Edition to JP1/AJS3 - Agent

If you need to execute more jobs on a computer where JP1/AJS3 - Agent Minimal Edition is running, you can do so by performing migration from JP1/AJS3 - Agent Minimal Edition to JP1/AJS3 - Agent.

To migrate from JP1/AJS3 - Agent Minimal Edition to JP1/AJS3 - Agent:

In Linux, specify Y in the environment variable JP1AJS3_FROM_LTDAGT_TO_AGT.

Install JP1/AJS3 - Agent.

For details about the installation procedure, see 2.2.3(2) Upgrade installation in the JP1/Automatic Job Management System 3 Configuration Guide (for Windows), or 12.2.6 Installation in Linux in the JP1/Automatic Job Management System 3 Configuration Guide (for Linux).

H. Version Revisions

For details on the version revisions, see B. Version Revisions in the manual JP1/Automatic Job Management System 3 Overview.

I. Reference Material for This Manual

For details on reference information that would be helpful in reading this manual, see C. Reference Material for This Manual in the manual JP1/Automatic Job Management System 3 Overview.

J. Glossary

For the glossary, see D. Glossary in the manual JP1/Automatic Job Management System 3 Overview.

Index

A

access permission to job executable files and script files[1]

access restriction (packet filtering)[1]

account

linking to mail service[1]

action jobs

environment settings[1], [2]

activating multiple scheduler services[1]

actual schedule and actual result data

acquiring[1]

adding

execution agent[1]

address translation[1], [2]

NAT (static mode)[1]

packet filtering[1]

agent

defining automatically[1]

Agent

JP1/AJS3[1]

agent host

method of determining[1]

agent management database[1]

agent pipe communication timeout (UNIX)[1]

amount of communications in line connections

estimating[1]

assigning

execution agent names and execution host names[1]

assumed JP1 user function

setting[1]

asynchronous job information deletion option[1]

automatic reorganization of ISAM database[1]

setting (UNIX)[1]

setting (Windows)[1]

B

backup

during JP1/AJS3 operation[1]

target files and timing[1]

backup and recovery

methods[1]

backups and recovery[1]

basics

communication[1]

firewall[1]

broadcast agent[1]

broadcast execution[1]

browsers

prerequisites[1]

C

CA (Certificate Authority)[1]

cautionary notes[1], [2]

character encoding

location of setting[1]

checking

operating environment[1]

CN (Common Name)[1]

common precautions

for jobs[1]

common settings

for JP1/AJS3 - View hosts[1]

for JP1 users[1]

notes on using[1]

setting environment[1]

common user profile[1]

usage example[1]

communication encryption function[1]

communication settings

for using JP1 in a firewall environment[1]

concurrent jobs

checking whether maximum number has been reached when jobs remain in queuing status[1]

concurrently executable jobs

maximum number[1], [2]

notes on setting maximum number[1]

configuration

example with firewall for cluster operation, and its communications settings[1]

example with firewall for non-cluster operation, and its communications settings[1]

queue/agent[1]

configurations

example of that include firewall, and their communications settings[1]

connection

user authentication[1]

connection examples

JP1/AJS3 - Agent connected to multiple LANs (connection to JP1/AJS3 - Managers)[1]

JP1/AJS3 - Agent connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Managers)[1]

JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Agents)[1]

JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Managers)[1]

JP1/AJS3 - Manager connected to multiple LANs (connection to JP1/AJS3 - Views)[1]

JP1/AJS3 - Manager connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Agents)[1]

JP1/AJS3 - Manager connected to multiple LANs for cluster operation (connection to JP1/AJS3 - Managers)[1]

JP1/AJS3 - View connected to multiple LANs (connection to JP1/AJS3 - Managers)[1]

connection source restriction[1]

considerations

disaster recovery[1]

installation and setup[1]

when using QUEUE jobs and submit jobs[1]

constant backup by copying and mirroring the disk[1]

contingency planning[1]

CSR (Certificate Signing Request)[1]

D

data

transfer time[1]

database

notes[1]

reorganization[1]

database area

estimating[1]

database areas

analyzing[1]

database backups

overview[1]

database errors

handling[1]

data collection tool

preparing[1]

defining

execution agents[1]

defining automatically

agent[1]

design

considerations[1]

flow[1]

designing

system configuration[1]

desktop heap area

using one specific to JP1/AJS3[1]

desktop heap size

adjusting by editing registry[1]

destination agent[1]

determining

JP1/AJS3 database configuration[1]

network configuration[1]

system configuration[1]

system environment settings[1]

dialog boxes

changing defaults[1]

disaster recovery

considerations[1]

overview[1]

disk capacity

estimating[1]

display item

adding to window[1]

DNS environment

notes on operation in[1]

operation[1]

drawing

time[1]

E

Editor / Monitor page[1]

encryption

of JP1/AJS3 communications with SSL[1]

environment setting parameter that defines log settings for email sending jobs that do not use Outlook[1]

environment settings

action jobs[1], [2]

for event jobs[1]

for user environment[1]

JP1/AJS3 - View[1]

JP1/AJS3 - Web Console[1]

QUEUE jobs and submit jobs[1]

queueless jobs[1]

regarding event jobs[1]

estimates[1]

data flow on the network[1]

data volume between JP1/AJS3 - Manager and JP1/AJS3 - Agent[1]

data volume between JP1/AJS3 - View and JP1/AJS3 - Manager[1]

data volume between user application and Web Console server[1]

data volume between Web Console server and JP1/AJS3 - Manager[1]

data volume between Web GUI and Web Console server[1]

scheduler trace log file size[1]

size of internal execution logs for queueless jobs[1]

size of queueless log file[1]

size of queueless trace log file[1]

size of scheduler log files[1]

size of the log information output by event jobs[1]

values for kernel parameters[1]

estimating

database area[1]

log file sizes[1]

log sizes[1]

processing performance of JP1/AJS3[1]

size of event job execution result log files[1]

size of job execution result log files[1]

size of log files for Web Console server[1]

size of logs output by execution environment for QUEUE jobs and submit jobs[1]

size of performance log files[1]

system performance[1]

estimating in disaster recovery environment

processing performance[1]

event job

processing performance[1]

event job processes and logs

default values[1]

event jobs

environment settings[1]

log setting configuration definition parameters[1]

setting log size[1]

event monitoring

performance[1]

event order option[1], [2]

EVJOBEXECRESULTLOG[1]

EVJOBEXECRESULTLOGPATH[1]

execution agent

adding[1]

default[1]

priority[1]

execution agent names and execution host names

assigning[1]

execution agents

defining[1]

grouping[1]

F

filtering conditions

example (for JP1/AJS3 - View and JP1/AJS3 - Manager)[1]

firewall

communication settings[1]

directions of traffic (JP1/AJS3)[1]

directions of traffic through[1]

flexible job

system configuration[1]

FQDN host names

example of using when DNS is used[1]

when to switch to using for event jobs[1]

function for reducing job status transition delays[1]

G

General page[1]

Glossary[1]

grouping

execution agents[1]

H

handling

database errors[1]

host

operation with multiple manager[1]

operation with single manager[1]

host name

example of in FQDN format defined in hosts file[1]

hosts file entries

example of specifying when alias is used for host name[1]

example of that enable hosts to resolve each other's host names[1]

HP-UX OS user groups[1]

I

installation

considerations[1]

notes on[1]

pre-installation decisions[1]

procedure[1]

intermediate certificate[1]

internal execution logs for queueless jobs

estimating size[1]

interval set when using the Monitoring Files job

monitoring[1]

IP address[1]

IPv6 address[1]

ISAM database

automatic reorganization[1]

maintenance[1]

QUEUE jobs and submit jobs[1]

ISAM file

automatic reorganization (UNIX)[1]

automatic reorganization (Windows)[1]

items affected by external factors and specifiable limits[1]

J

job

processing performance[1]

job distribution delay reduction function[1]

JOBEXECRESULTLOG[1]

JOBEXECRESULTLOGCOUNT[1]

JOBEXECRESULTLOGPATH[1]

JOBEXECRESULTLOGSIZE[1]

job execution

options related to[1]

job execution among multiple agent hosts

distributing[1]

job execution control manager (jpqman)

reducing memory usage[1]

job execution environment

setting[1]

job information

deleting asynchronously[1]

disabling deletion at JP1/AJS3 startup[1]

jobs with long file names

executing (Windows only)[1]

job throughput[1]

JP1/AJS

check version[1]

JP1/AJS3

Agent[1]

Manager[1]

preparatory estimates and settings[1]

prerequisites[1]

programs[1], [2]

View[1]

JP1/AJS3 - Agent

cases where connected to multiple LANs to execute jobs in cluster configuration[1]

setup[1]

JP1/AJS3 - Agent Minimal Edition[1]

JP1/AJS3 - Agent port numbers[1]

JP1/AJS3 Autonomous Agent Messenger service[1]

JP1/AJS3 Autonomous Agent service[1]

JP1/AJS3 Check Agent service[1]

JP1/AJS3 Check Manager service[1]

JP1/AJS3 commands that can be executed from JP1/AJS3 - View[1]

JP1/AJS3 communications[1]

JP1/AJS3 database

configuration[1]

JP1/AJS3 Database ClusterService service[1]

JP1/AJS3 database configuration[1]

determining[1]

JP1/AJS3 databases

tables[1]

types of[1]

JP1/AJS3 Database service[1]

JP1/AJS3 design

steps[1]

JP1/AJS3 for x86 in WOW64 environment

notes[1]

JP1/AJS3 host settings

notes[1]

JP1/AJS3 HTTP Server service[1]

JP1/AJS3 Mail service[1]

JP1/AJS3 - Manager

cases where connected to multiple LANs in cluster configuration[1]

processing time[1]

restricting usage to submit job registration and operation (UNIX)[1]

restricting usage to submit job registration and operation (Windows)[1]

setup[1]

JP1/AJS3 - Manager and JP1/AJS3 - Agent

communications between[1]

JP1/AJS3 - Manager and JP1/AJS3 - Manager

communications between[1]

JP1/AJS3 - Manager and JP1/Base

communications between (authentication server)[1]

JP1/AJS3 - Manager and other programs

communications between[1]

JP1/AJS3 - Manager port numbers[1]

JP1/AJS3 Queueless Agent service[1]

JP1/AJS3 Queueless File Transfer service[1]

JP1/AJS3 service[1]

JP1/AJS3 services

changing to user account[1]

defaults (Windows)[1]

privileges for user account[1]

settings[1]

settings for automatically starting and stopping[1]

JP1/AJS3 system operation

operations that might affect[1]

JP1/AJS3 - View

environment settings[1]

response[1]

JP1/AJS3 - View and JP1/AJS3 - Manager

communications between[1], [2]

JP1/AJS3 - View common user profile

usage example[1]

JP1/AJS3 - View port number[1]

JP1/AJS3 Web Application Server service[1]

JP1/AJS3 - Web Console

environment settings[1]

JP1/AJS3 - Web Console port number[1]

JP1/Base

check version[1]

JP1/Base communications[1]

JP1/Power Monitor

required changes for linking to[1]

jp1hosts information or jp1hosts2 information

defining[1]

jpqendjobshow command

action when too many jobs are enumerated[1]

jpqjobshow command

action when too many jobs are enumerated[1]

K

kernel parameter

estimating the values[1]

L

LANG environment variable

values that can be specified[1]

language type and character encoding[1]

limits

Limits for queueless job execution control[1]

Limits for scheduler services[1]

Limits for the definition pre-check function[1]

Limits for the event/action control[1]

Limits for the job execution environment[1]

Limits for the submit job execution environment[1]

Limits for units[1]

Limits for using operation profiles[1]

Limits on file sizes[1]

Limits on the number of JP1/AJS3 product connections[1]

list[1]

limits to prevent system-wide effects from external factors[1]

linking with mail system[1]

load distribution[1], [2]

log configuration definition

environment setting parameters in one for execution environment of QUEUE jobs and submit jobs[1]

log file

formula to estimate the size[1]

log file sizes

estimating[1]

logical host[1]

log information output by event jobs

estimating the size[1]

Login page[1]

login script

modifying[1]

login shell

precautions[1]

Login shell at job startup (Unix jobs, flexible jobs, HTTP connection jobs, and action jobs)[1]

LogNumFiles[1], [2]

log setting configuration definition parameters for event jobs[1]

LogSize[1], [2]

log size

calculating for each process[1]

LogSize_EmbeddedMail[1]

Log size (rough values) for each event job process[1]

log sizes

estimating[1]

long file name

job execution (Windows)[1]

M

Main page[1]

maintenance

estimating when to perform[1]

maintenance mode

estimating frequency[1]

notes[1]

purpose[1]

maintenance planning[1]

maintenance tasks

flow[1]

Manager

JP1/AJS3[1]

manager/agent configuration

cautions[1]

maximum number of concurrently executable jobs[1]

messages

indicating area shortage[1]

migration

from previous version[1]

of definitions from JP1/AJS2 to JP1/AJS3[1]

Monitoring Files job

passing status of[1]

monitoring interval

estimating[1]

example estimation of time set for Monitoring Files jobs[1]

time estimation formula[1]

multiple instances of JP1/AJS3 services

starting[1]

multiple scheduler services

activating on UNIX host[1]

when activated and you want to avoid desktop heap shortages[1]

multiple scheduler services concurrently

activating[1]

multiple scheduler services on Windows host

activating[1]

multiuser remote desktop connections to JP1/AJS3 - View

considerations for[1]

N

NAT[1]

example of setting with JP1/AJS3[1]

NAT (Network Address Translator)[1]

network address translation (NAT)[1]

Network Address Translator[1]

network configuration

determining[1]

network error

job retry process[1]

network resources

when using[1]

O

OpenSSL[1]

operating environment

checking[1]

operating system

that can run JP1/AJS3 series programs[1]

operating systems

prerequisites[1]

operation

special modes[1]

options

for job execution[1]

OS

check version[1]

tuning[1]

OS user environment

when a job is executed[1]

OS user environment for job execution[1]

other

prerequisites[1]

other cautionary notes[1]

Other page[1]

overview

disaster recovery[1]

P

packet filtering[1]

example of setting with JP1/AJS3[1]

passing event data containing double quotation marks[1]

pipe communication timeout value

setting for agent (UNIX only)[1]

port numbers[1], [2]

tables[1]

port numbers for communications

from JP1/AJS3 - Agent (broadcast agent) to JP1/AJS3 - Agent (destination agent)[1]

from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (broadcast agent)[1]

from JP1/AJS3 - Agent (relay agent) to JP1/AJS3 - Agent (destination agent)[1]

from JP1/AJS3 - Agent to JP1/AJS3 - Manager[1]

from JP1/AJS3 - Manager to JP1/AJS3 - Agent[1]

from JP1/AJS3 - Manager to JP1/AJS3 - Manager[1]

from JP1/AJS3 - View to JP1/AJS3 - Manager[1]

from JP1/AJS3 - Web Console to JP1/AJS3 - Manager[1]

from web browser to JP1/AJS3 - Web Console[1]

ports used for communications

between JP1/AJS3 - Agent and JP1/AJS3 - Agent[1]

between JP1/AJS3 - Manager and JP1/AJS3 - Agent[1]

between JP1/AJS3 - Manager and JP1/AJS3 - Manager[1]

between JP1/AJS3 - View and JP1/AJS3 - Manager[1]

between JP1/AJS3 - View and JP1/Base[1]

between web browser and JP1/AJS3 - Web Console[1]

port used for communications

between JP1/AJS3 - Web Console and JP1/AJS3 - Manager[1]

Preferences dialog box[1]

settings[1]

preparing

data collection tool[1]

privileges for running JP1/AJS3 services under user account[1]

processing events in order of occurrence[1]

processing performance

estimating[1]

estimating in disaster recovery environment[1]

processing performance of JP1/AJS3

estimating[1]

programs

prerequisites[1]

programs that use code functions

notes[1]

Q

QUEUE jobs

setup for using[1]

QUEUE jobs and submit jobs

database[1]

database tables[1]

execution environment[1]

execution environment settings[1]

job execution control[1]

maximum number of concurrently executable jobs[1]

method of determining agent host[1]

queueless jobs

considerations[1]

execution environment settings[1]

queueless log file

estimating size[1]

estimation formula[1]

queueless trace log file

estimating size[1]

estimation formula[1]

R

redundancy[1]

example[1]

Reference Material for This Manual[1]

refresh interval[1]

relay agent[1]

remote desktop

multiuser connections to JP1/AJS3 - View[1]

response

user applications that use API functions[1]

restrictions

on file reception[1]

on file transmission[1]

retention period for job information

setting[1]

retry

job retry process if a network error occurs[1]

root certificate[1]

S

SAN (Subject Alternative Names)[1]

save status setting[1]

enabling[1]

Schedule page[1]

scheduler database[1]

restoring from unload log files[1]

restoring without using system log[1]

supplementary notes about[1]

scheduler database tables[1]

scheduler log file

example estimate[1]

formula for estimating the size[1]

scheduler log file size

expanding[1]

scheduler service[1]

concurrent activation[1]

scheduler trace log file

estimating the size[1]

search path for transfer files[1]

server certificate[1]

service account

when to change[1]

service defaults

changing[1]

JP1/AJS3 - Manager, JP1/AJS3 - Web Console, and JP1/AJS3 - Agent services[1]

services

types[1]

setting

assumed JP1 user function[1]

job execution environment[1]

retention period for job information[1]

setup

considerations[1]

JP1/AJS3 - Manager[1]

setup considerations[1]

single agent host as multiple execution hosts

using[1]

size of common log

changing for events and actions[1]

size of log files

estimating for JP1/AJS3 - View[1]

size of logs

estimating output by execution[1]

guide to output in execution environment QUEUE jobs and submit jobs[1]

size of logs output by execution environment for QUEUE jobs and submit jobs

estimating[1]

size of memory used

estimating[1]

SSL

encryption of JP1/AJS3 communications [1]

SSL (Secure Sockets Layer)[1]

submit job execution order

notes[1]

setting for preventing changes[1]

submit jobs

setup for using[1]

support status

communication settings for functionality provided by JP1/AJS3[1]

synchronous write mode[1]

system common settings file[1]

system configuration

designing[1]

determining[1]

example[1]

example of for creating cluster system[1]

example of for executing work tasks on single host[1]

example of manager/agent (multiple manager hosts)[1]

example of manager/agent (one manager host)[1]

example of standalone[1]

example of with firewall[1]

examples of manager/agent[1]

notes on manager/agent[1]

system configuration examples

checking execution statuses on multiple hosts for administrative tasks in different time zones[1]

creating a cluster system[1]

firewall is set[1]

JP1/AJS3 - Manager connected to multiple LANs in cluster system (connection to JP1/AJS3 - View)[1]

system configurations

recommended[1]

system design

key decisions[1]

notes[1]

overview[1]

system environment settings

determining[1]

system files

duplicating[1]

system performance

estimating[1]

T

table

definition tables[1]

execution tables[1]

TCP/IP

parameters[1]

time zone[1]

TLS (Transport Layer Security)[1]

trace level[1]

translation

address (NAT)[1]

translation rule

example of (translating 150.150.150.15 to 200.200.200.20)[1]

U

unit definition data

updating[1]

units

operations on[1]

Unix jobs and flexible jobs

precautions for[1]

unload log file[1]

unload log files

using[1]

upgrading

notes[1]

user account at job execution[1]

user preferences[1]

using

single agent host as multiple execution hosts[1]

UTF-8 code

notes on using[1]

V

values

that can be specified in LANG environment variable[1]

verifying JP1/AJS3 operations

examples[1]

verifying legitimacy of JP1/AJS3 operations

functions[1]

functions and operating modes[1]

version compatibility[1]

between JP1/AJS3 - Manager and JP1/AJS3 - Agent[1]

between JP1/AJS3 - Manager and JP1/AJS3 - View[1]

between JP1/AJS3 - Manager on different hosts[1]

between JP1/Base and JP1/AJS3[1]

Version compatibility

between JP1/AJS3 - Manager and JP1/AJS3 - Web Console[1]

version revisions[1]

versions

different versions of JP1/AJS3 - Manager and JP1/AJS3 - View[1]

View

JP1/AJS3[1]

W

WAN

communications used in[1]

Web GUI

response[1]

wildcard certificate[1]

window display[1]

work path

defining as variable[1]

work path for job execution

defining as a variable[1]