5.8.3 Partition Definitions - Create, Change or Delete
When an existing partition has been selected for display (and possible change or delete) or the add function key has been used to indicate that a new partition is to be defined, the System Partition screen is displayed.
|
|
Note: The change and delete command keys are only enabled when reviewing the definition of an existing partition. The and options only appear when you are defining a new system partition.
Working from the System Partition it is possible to:
- Input details of a new partition.
- Review details of an existing partition.
- Use the change function key to indicate that the partition definition is to be changed. If this option is used the screen will be re-presented with some fields input capable. Make the desired changes and press enter to proceed.
- Use the delete function key to indicate that the partition is to be deleted. If this option is used, a screen will be displayed to submit the deletion job to batch. You must confirm that the partition is to be deleted by entering YES. No other job should be using the partition when the deletion job executes. A user profile which is the LANSA system owner or part of that group should be used to execute the deletion job. It is recommended that a REORG of the LANSA system be run after the deletion has completed. For REORG details, refer to 5.6 Reorganizing the LANSA Internal Database. This deletion will not remove objects from the partition's module library or the partition's file library. These libraries or the LANSA objects should be deleted using IBM i commands.
Note: The system partition SYS cannot be deleted. Neither can the partition that is currently being used/worked with.
Input Options
The following input options apply when specifying details of a new partition definition or changing details of an existing partition definition:
Partition Identifier
Specifies identifier / mnemonic assigned to the partition. Must be 3 characters long and consist of 'A' -> 'Z', '@', '#', '$', '0' -> '9' only. It must be unique. No two partitions can have the same identifier.
Partition Description
Specifies the description of the partition. Must not be blank.
Module Library
Specifies the name of the library in which compiled RDML programs associated with this partition are kept. The library must currently exist and must not be the same as the module library used by any other partition. Once specified, the name of the module library cannot be changed. Do not use the LANSA system program and data libraries.
Unique Object Prefix
Specifies a unique object naming prefix that is to be used by LANSA for this partition. This prefix is used internally by LANSA within its database and externally in the name of the compiled RPGIII programs it produces from RDML source statements.
The prefix must be alphabetic in the range 'D' - 'Z', '@', '$' or '#', or 0 - 9 and unique. No two partitions can have the same prefix. Once established the prefix for a partition cannot be changed.
Security Officer
Specifies the name of the IBM i user profile who is to be the security officer for the partition. The profile must exist and does not have to be QSECOFR.
A user profile that is nominated as a partition security officer does not have any special rights in other partitions or outside of the LANSA system.
Default File Library
Specifies the name of the library that is to be the default library for new files created in this partition. Note that this is a default value only and does not restrict users of the partition from creating files in other libraries. Do not use the LANSA system program and data libraries.
Warnings:Avoid using the library specified here as the IBM i 'current library' in any interactive or batch job.
Include in Library List
Requests that you specify whether or not the default file library for this partition is to be automatically included in the job's library list when accessing this partition.
Allowable values are:
|
NO |
The default file library is not to be included into the job's library list. |
|
YES |
The default file library is to be included into the job's library list. |
The default value is NO.
Warning
If the default file library is changed, all Visual LANSA slaves will require Files that have a library equal to the previous default file library to have JUST THE OAM re-built. This will retain existing data. If the table is re-built, existing data will be lost.
Initial Public Access
Appears only when defining a new partition. Specifies what access to the partition is to be allowed to other system users initially. Allowable values are:
|
NORMAL |
Other system users can use this partition but cannot change its definition or delete it. |
|
ALL |
Other system users can use this partition and can change its definition or delete it. |
|
NONE |
Other system users cannot access this partition. |
After a partition has been created individual or public access to it can be displayed or modified by the option available on the Housekeeping menu.
Library for Help Panel Groups
This item is shown only if Panel Groups are used in this LANSA system for the presentation of HELP text (see section on 'using Panel Groups for HELP text'). The specification of a library name is optional. If no library is specified, any Panel Groups created in monolingual systems, or the Panel Groups created for the default language in multilingual systems, will be placed into the partition's module library. If a library is specified, these Panel Groups created will be placed into this library. The library does not need to exist when the name is specified here. It will be created, if required, when the first Panel Group is compiled.
This library will be added into the library list at the start of a LANSA session. It should be specified, if required, before panel groups are created for this partition, and should not be changed later. If the library specified here is changed after panel groups have been created, these Panel Groups should be moved to the new library, or deleted and re-created, so that the HELP text is found at execution time. This is the user's responsibility.
Copy System Field From
Appears only when defining a new partition. Optionally allows all 'system' field definitions to be copied from an existing partition into the new partition.
Certain fields defined within LANSA are required in any partition for it to be used effectively. Some examples include IO$STS and @@UPID. In addition a number of user defined fields may be considered as vital and be flagged as 'system' fields. Refer to the field definition section of this guide for of how system fields are defined.
The default value for this option is 'SYS', which indicates that all system fields from partition 'SYS' should be copied to this new partition.
Either accept the default of 'SYS' or specify the name of another partition from which the definition of system fields should be copied. Leave blank to avoid copying any system fields.
System frameworks and groups will also be copied from the nominated partition. For more information, refer to the Visual LANSA documentation.
SAA/CUA Standards Apply
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not SAA/CUA (System Application Architecture / Common User Access) standards apply to objects created within this partition.
Allowable values are:
|
YES |
SAA/CUA standards apply to this partition. |
|
NO |
SAA/CUA standards do not apply to this partition. |
The default value is YES.
Before attempting to change or create a partition that uses SAA/CUA standards read in full 5.8.5 If you Comply with SAA/CUA Standards and Guidelines and IBM i SAA/CUA Implementation in the .
Multilingual Support
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not this partition requires multilingual support.
It is recommended that all partitions are defined as multilingual even if they will be used with only one language.
Allowable values are:
|
YES |
Multilingual support is required for this partition. |
|
NO |
Multilingual support is not required for this partition. |
The default value is YES.
If you specify YES then you must also specify YES for the SAA/CUA standards apply option.
Before changing or creating a partition that uses multilingual support, read Setting Up LANSA to Run Multilingual Applications in the as well as the Note following.
Note:
There are some important things that you should know about multilingual support before you attempt to turn it on (or off):
- Providing (or not providing) multilingual support in your applications is an important application design decision that you should make decisively, even before LANSA installation. Changing your mind later (or changing your mind multiple times) may lead to unnecessary and avoidable maintenance and deployment issues. Refer to Imports with the LANSA IBM i Software in the for a list of LANSA software that requires a multilingual partition.
- There are important procedures, considerations and guidelines that you should understand and then follow when converting a partition from monolingual form to multilingual form (or vice versa).
- Changing a partition to multilingual or monolingual form impacts the repositories in attached Visual LANSA development workstations. You must take steps to ensure that your central repository and all attached Visual LANSA workstation repositories are changed in a synchronized fashion. In outline, the simplest way to ensure this synchronization is as follows:
- Check in all new or modified objects from all attached Visual LANSA workstations into the central repository.
- Delete the partition from all attached Visual LANSA workstations.
- Change the central repository to/from multilingual form.
- Make the changes to object definitions in the central repository as specified in the .
- Set up the partition again on all attached Visual LANSA workstations as if it was a brand new partition, and then verify that it now has the correct multilingual characteristics (or not).
- Check out all required objects to each attached Visual LANSA workstation.
Help Option on Menus
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not a 'help' option is to appear on process menus, and if it is to appear, what the text that is to be displayed should be.
The default is 'Display process or function HELP text'.
Change the text as required, particularly if you are running a system in a language other than English.
Otherwise specify *NONE (in uppercase characters) to indicate that the help option is not required on process menus. Note that the non-appearance of this option as a menu option does not prevent the user from using the help function key(s).
Recompile any compiled process menus after changing this option.
Return Prefix on Menus
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not a 'return' option is to appear on process menus, and if it is to appear, what the prefix of what is displayed should be.
The default is 'Return to'.
Change the prefix as required, particularly if you are running a system in a language other than English.
Otherwise specify *NONE (in uppercase characters) to indicate that the return option is not required on process menus. Note that the non-appearance of this option as a menu option does not prevent the user from using the cancel function key.
Recompile any compiled process menus after changing this option.
Exit Option on Menus
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not an 'exit' option is to appear on process menus, and if it is to appear, what the text that is to be displayed should be.
The default is 'Exit from system'.
Change the text as required, particularly if you are running a system in a language other than English.
Otherwise specify *NONE (in uppercase characters) to indicate that the exit option is not required on process menus. Note that the non-appearance of this option as a menu option does prevent the user from using the exit function key.
Recompile any compiled process menus after changing this option.
Keep Translated RPG / Keep Translated DDS
Appears when defining a new partition or changing an existing partition. Requests that you specify whether or not:
|
DDS |
(Data Description Specifications) translated from your LANSA requests should be permanently kept. |
|
RPG |
(Report Program Generator) source statements translated from your LANSA requests should be permanently kept. |
The default for both these options is NO (source statements are not to be kept). Keeping source statements in most situations is just a waste of disk space.
However, if you specify YES to request that either translated DDS or translated RPG be kept, please take note of the following very important points:
- If you specify YES, you must specify both a source file name and a library name. *LIBL is not acceptable as the library name. The file and library name you specify are not validated in any way, so check what you specify carefully.
- The source files nominated should be created before they are made known to LANSA. Use the CRTSRCPF (Create Source Physical File) command to do this. The existence of the nominated files is not checked.
- The same source file should not be specified for the storage of both DDS and RPG. This is not checked.
- No two partitions should share the same source files for the storage of translated RPG or DDS. This is not checked.
- Stored translated DDS or RPG is not automatically imported or exported by the LANSA export/import facilities. If this facility is required it must be defined to the export/import routines as if 'non-LANSA' objects are being shipped. The setup and correct execution of such facilities is a user responsibility.
- When LANSA file, process or function definitions are deleted, any associated translated DDS or RPG is not removed from the source files specified.
- When LANSA file, process or function definitions are recreated or recompiled, any translated DDS or RPG is replaced by the newer version resulting from the recreate or recompile.
- Translated RPG may be moved to another CPU, but it cannot ever be successfully executed by moving it this way, even if LANSA is resident on the target machine.
The only way to move field, file, process or function definitions between machines is via the LANSA import/export facilities.
- Translated RPG code is not intended for maintenance by 'human beings'. The translated code is very cryptic and would be very difficult to effectively maintain at the RPG level.
Remember that LANSA is based on a fully procedural RDML language. All development and maintenance work should be done at the RDML level. RPG is used as a 'vehicle' to produce executable program objects. Its existence should be invisible and immaterial to RDML application programmers.
LANSA is not designed to be an RPG generator. This is why the word 'translated' is used throughout this section.
- If stored DDS or RPG are manually modified and then used to recreate or recompile LANSA objects, all maintenance and support for the object(s) involved will be suspended. If you create problems by doing this, your product vendor may help you to correct them, but is in no way obliged to do so.
This table identifies the types of source members that may be placed into source files:
|
where:
innnnn is the internal function identifier derived from field F23FID in file DC@F23.
fffffff is the actual 1 to 7 character function name derived from field F23FMT in file DC@F23.
Note: The external data member is used to create an externally described data structure in library QTEMP during compiles. After the compile completes it ceases to exist. It is used to ensure that even-length packed fields are handled correctly.
Configure Task Tracking
Displayed when defining a new partition or changing an existing partition. Configure task tracking is split into the following six questions, each requiring a YES or NO answer. These answers will define how task tracking will operate within this partition.
1. Is Task Tracking active within this partition?Allowable values are:
|
YES |
Task Tracking is active in this partition, object and task authority checks will be performed and all events that have taken place for work performed on objects will be recorded. |
|
NO |
Task Tracking is not active in this partition. |
The default value is NO.
2. Does the user require a task identifier to do work?Allowable values are:
|
YES |
User does require a task identifier before any work can be performed on a selected object. |
|
NO |
User does not require a task identifier to do work, until work has been completed on a selected object, where on he/she will be prompted by a POPUP window to allocate a task identifier against the selected object. |
The default value is NO.
Note: This option will be ignored if Task Tracking is not active in this partition.
3. Prompt/Confirm task identifier?Allowable values are:
|
YES |
Prompt/confirm task identifier is required when work has completed on a selected object. The user will be prompted with the 'Prompt/Confirm POPUP Window' to confirm or change (if CHANGE function key is enabled) the task identifier to be allocated for work performed on the selected object. |
|
NO |
Prompt/confirm task identifier is not required. The task identifier specified for this job (on entry into LANSA or by a previous request to specify a task identifier for the job via the 'Prompt/Confirm POPUP Window'), will be automatically confirmed as the task identifier for work performed on the selected object. |
The default value is NO.
Note: This option will be ignored if Task Tracking not active in this partition.
4. Allow user to change tasks while working?Allowable values are:
|
YES |
User is allowed to change the task identifier that is allocated to the selected object on which work was performed but only if the user is authorized to the task identifier, OR, if the 'Prompt/Confirm POPUP Window' is displayed, the CHANGE function key will be enabled to allow the user to change task identifiers manually. |
|
NO |
User not allowed to change tasks. |
The default value is NO.
Note: This option will be ignored if Task Tracking is not active in this partition.
5. Disable Special 'Work with Tasks' Security?
Allowable values are:
|
YES |
Disable the special security checks within the 'Work with Tasks' option. |
|
NO |
The special security checks within the 'Work with Tasks' option are active. |
The default value is NO.
This option will be ignored if Task Tracking is not active in this partition.
6. Activate Task Tracking for Import jobs?Allowable values are:
|
YES |
Task tracking is active for import jobs |
|
NO |
Task tracking is not used for import jobs. |
The default value is NO.
This is only used if Task Tracking is active in a partition.
Note: Special security checks ensure that only QSECOFR, the Partition Security Officer or a user belonging to one of these groups has access to the Work with Tasks option. Whether special Work with Tasks security is disabled or not, normal menu security still applies to Work with Tasks.
Task Identifiers are allocated using the 5.5.2 Create a Task Identifier option on the Work with Tasks menu.
When Task Tracking has been activated for a partition, invoke LANSA by using the LANSA command and passing the partition parameter (PARTITION) and the task identifier parameter (TASK_ID). The following example demonstrates how to invoke LANSA when Task Tracking is active:
LANSA PARTITION(DEM) TASK_ID(00000001)
Before attempting to configure Task Tracking please read the section that details the requirements and considerations of 5.4 Task Tracking in LANSA.
Enable for full RDMLX
This option appears when defining or changing an existing partition so that you can specify whether or not this partition is to allow full RDMLX objects.
Before changing or creating a partition that is enabled for full RDMLX, read the RDML and RDMLX Partitions Concepts for details of the requirements and conditions for RDMLX development.
Allowable values are:
YES full RDMLX is required for this partition.
NO full RDMLX is not required for this partition.
The default value is NO.
If you specify YES, you will be asked to confirm your selection. Once a partition is enabled for full RDMLX:
- it cannot be returned to a non-RDMLX state
- all development must be done in Visual LANSA
- development in LANSA for i is NOT permitted.
If you select YES to enable the partition for full RDMLX, you will need to specify further options, as described in 5.8.4 If you Enable a Partition for Full RDMLX.
Enable Documentor
Specifies that LANSA/DOCUMENTOR is to be enabled in this partition. Before enabling Documentor, please read the section that explains the requirements and considerations of using the Documentor.
Enforce User Access in Visual LANSA
This option can be used to control User Access in slave Visual LANSA systems. Enter YES if you wish to control User Access in the slave Visual LANSA systems in accordance with defined User Access in this IBM i master system partition.
The default is NO.
Ignore Propagated Deletes
This option can be used to control the processing of propagated deletes in slave Visual LANSA systems. Enter YES if you wish propagated deletes to be ignored in the slave Visual LANSA systems.
The default is YES.
Check Before Propagating
This option can be used to control the processing of propagated deletes in slave Visual LANSA systems. Enter YES if you wish referential checks to be performed before actioning propagated deletes on the slave Visual LANSA systems. This will prevent, for example, the deletion of a field that has been used in a local file.
Force *ENDWHERESQL
For use by Visual LANSA with the SELECT command to differentiate between the use of SQL or native I/O access. Refer to the OPTIONS parameter in the SELECT Parameters for details.
The default is NO.
Enable Short Char
Select through to as required.
Default is zero (which is Disable).
For details, refer to Enable Short Char in the .
Changing a partition's can alter the structure of LANSA working lists that contain one or more fields of type string and/or char. This altered structure is not compatible between LANSA objects that share the working list unless all these objects are rebuilt. If you do change it, you must rebuild all the files, functions, forms and reusable parts in the partition in order to avoid unpredictable behaviors at runtime.
Enable Long Names
Apart from setting this option, Yes or No, long names, if used, are entered via the Visual LANSA system.
For details, refer to in the
Target Database Products
Enter YES for Database Products you wish to use with your IBM i or Visual LANSA application.
Different database products have different requirements for field types, lengths, etc. Setting these flags will help ensure that files created in your application can be supported in the database.