Introduction
The diagram below depicts an Endevor configuration that includes the optional package shipping feature.
Any number of stages may exist in an Endevor life cycle from start to finish. Typically at least one of the initial stages is available without requiring the use of a package. For the remaining stages, packages are required in order to group software changes together for approvals and promotions. Stages at the end of the life cycle support shipments to deploy package outputs to Remote Destinations.
At every stage of the life cycle processors build outputs, and execute functions such as DB2 Binds and CICS newcopies.
Despite that Shipments start with Endevor, actions that run on a Remote site are no longer Endevor actions. Instead, they run as pure JCL and IBM utiiities, void of Endevor-related software. There is no requirement that Endevor be found at a remote Site. Typically, as a result, there is no opportunity to execute processors at a Remote site. However, the Post-Ship Scripts option compensates for the lack of processors and allows you to execute similar actions.
In this blog, we dive into the configuration details of package shipping and Post-Ship Scripts. Examples show how to prepare and deliver services such as executing DB2 Binds, CICS newcopies, and ADDing elements into another Endevor. If the examples do not address your specific interests, it is hoped that they provide sufficient detail to help you along the way.
How to Start a Package Shipment
A package shipment can be initiated from Endevor panels as described in Build a Shipment Request.
If you are not already familiar with these, see the What are the three Package Shipping Jobs and the Shipping Job Names sections of this document.
Also to review the many setup options for Package Shipping, see How Processors and Type Definitions Affect Package Shipping through More Package Shipping Choices.
What are the three Package Shipping Jobs
For each package shipment, there are at least three package shipping jobs constructed and submitted. If the transmission tool is Netview FTP, then there are two Host jobs, bringing the total number of shipping jobs to four.
-
Host job runs where the Endevor shipment is initiated. It identifies the dataset and member names that were impacted by the package execution. The Host job sends members to the remote system and submits the Remote job via your chosen Transmission tool.
-
Remote job - copies members into the remote target libraries defined by your library mapping rules. Optionally, it executes services you have defined as Post-Ship Scripts. Finally, the Remote job submits the Confirmation job.
-
Confirmation job submitted from the remote Destination runs on the Host system and notifies Endevor of the success or failure of the remote actions.
Shipment Job Names
The HOST and Confirmation job names are derived from the jobcard information entered into the package ship panel (C1SP9000) by the requestor.
The Remote JOBCARD comes from the Destination definition panel and is stored in Endevor.
How Processors and Type Definitions Affect Package Shipping
Successful package shipping is dependent upon the proper configurations of your Endevor processors and Type definitions. If you plan to use the Destination Configuration Member (find Destination Configuration) feature of package shipment there may be an impact on your processors. For more, see the (optional) Define a Destination Configuration member section of this document.
Nevertheless, processors can prevent the package shipments of outputs. For example, if IEBCOPY is used rather than BSTCOPY, or if your processor includes a “BACKOUT=N” clause, then you may be excluding datasets from shipments.
“Source Libraries” (aka Source Output Libraries SOL) on your Type definitions are automatically eligible for shipment. No processor support is required for them. However, “Base” libraries are not able to be shipped. If you use a JCL library defined as a “Base” library, you might also need to define a SOL library or code a processor to populate a JCL library. Otherwise, your JCL members cannot be shipped.
You can view the shipping condition for a given package by viewing the Display Data Set Backout Info package display.
The objects shown as backout information also represent objects eligible for package shipments. For example, this package display shows that LOADLiB members and LISTLIB members for two elements are eligible for shipping. Also eligible is a member of a JCL library.
If your package contains actions for elements that do not appear in the package display, then they cannot be shipped. The Type or processor configuration excludes them.
Of the eligible libraries for a package, a Destination’s Library Mapping rule determines which libraries are actually shipped. See the Create a Destination section of this document for more.
Create a Destination
See the techdocs documentation for creating a Destination. If you need to create many destinations or want to use a batch process to build them then:
Some transmission tools allow you to use an IP address for a REMOTE NODENAME. If you log onto a remote site and issue the command “TSO HOMETEST”, you can capture an IP address for that site.
Each Destination definition may include Library Mapping Rules. Follow the directions in Mapping Rules. If no Library Mapping Rules are defined, then file names at the Destination are expected to match those from the Host (sending) site. Also, each Host site library name is expected to ship and be physically present at the Remote site.
A Library Mapping rule identifies an eligible Host library name (or a mask for multiple libraries) to select for shipment and names a corresponding remote library to be targeted.
The example Mapping Rule below selects libraries named SHARE.ENDV.PRC.*.JCL00 from a package’s Display Data Set Backout Info display, and targets the PSP.ENDV.TEAM.JCL00 library for shipments.
MODIFY ------------------ MODIFY DSN MAPPING RULE ---------------------------
OPTION ===>
blank - Modify Rule # - Delete Rule
DESTINATION: PSPLIBS
MAPPING RULE DESCRIPTION ===> SHARE.ENDV.PRCS.*.JCL00
To EXCLUDE datasets from being transmitted, leave REMOTE DSN blank.
For SCRIPT datasets, use the value (SCRIPT-FILE) in the REMOTE DSN.
HOST DATASET NAME ===> SHARE.ENDV.PRCS.*.JCL00
maps to
REMOTE DATASET NAME ===> PSP.ENDV.TEAM.JCL00
Approx Host Members/Cyl ===> 16
MAPPING RULE DSNs PRIOR TO MODIFICATION:
HOST: SHARE.ENDV.PRCS.*.JCL00
REMOTE: PSP.ENDV.TEAM.JCL00
While working with a Destination you can view all the mapping rules. Here is an example.
------------------------ DSN MAPPING SELECTION LIST --------Row 1 to 9 of 9
COMMAND ===> SCROLL ===>PAGE
DESTINATION:CA66FIN
S MESSAGE STATUS ------------ HOST DATASET NAME ------------- UPDATED
MAPPED SYSDE32.NDVR.PRD.*.CICSNEWC 30SEP23
MAPPED SHARE.ENDV.PRCS.*.JCL00 29SEP23
MAPPED SYSDE32.*.*.*.*.LOADCICS 30SEP23
MAPPED SYSDE32.*.*.*.*.LOADLIB 29SEP23
EXCLUDED *.* 29SEP23
EXCLUDED *.*.* 29SEP23
EXCLUDED *.*.*.* 29SEP23
EXCLUDED *.*.*.*.* 29SEP23
EXCLUDED *.*.*.*.*.* 29SEP23
******************************* Bottom of data ********************************
A popular scheme for Library Mapping is to cause only mapped libraries to be shipped. That scheme is accomplished by using EXCLUDE statements like those at the bottom of this example display.
When a package shipment runs, a “Reference” (find AHREF) file is created that shows package shipping details. Within the Reference file, you find Host and Remote libraries as defined in the mapping rules, and the names of “Staging” libraries. Here is an example “Reference” file for a shipment that occurred on October 2.
SHIPMENT DATASETS
HOST LIBRARY: SYSDE32.NDVR.PRD.FINANCE.ACCTPAY.LISTLIB
*
SHIPMENT DATASETS
HOST LIBRARY: SYSDE32.NDVR.PRD.FINANCE.ACCTPAY.LOADCICS
HOST STAGING: PUBLIC.HOST.D231002.T131843.CA66FIN.AH004
REMOTE STAGING: PUBLIC.RMOT.D231002.T131843.CA66FIN.AR004
REMOTE LIBRARY: CADEMO.ENDV.PRCS.PROD.LOADC00
*
SHIPMENT DATASETS
HOST LIBRARY: SHARE.ENDV.PRCS.FINANCE.JCL00
HOST STAGING: PUBLIC.HOST.D231002.T131843.CA66FIN.AH003
REMOTE STAGING: PUBLIC.RMOT.D231002.T131843.CA66FIN.AR003
REMOTE LIBRARY: PSP.ENDV.TEAM.JCL00
*
This AHREF file shows that JCL and program members were updated by this package and shipped. However, LISTLIB members were “Excluded” from Shipment via the Library mapping rules.
When both a HOST Dataset name and a REMOTE Dataset name are specified, then Package shipping will copy members in this manner
-
A Host Job will copy package output members from a HOST library to a HOST STAGING library
-
A Host Job will transmit a HOST STAGING library to a REMOTE STAGING library
-
The Remote job will copy members from the REMOTE STAGING library to the REMOTE LIBRARY
If you are shipping Endevor-managed USS files to a Remote site’s USS directories, see
How to Enable USS Supported Files for Package Ship. On the other hand, if you need to ship PDS members to Remote USS Directories see the Shipping PDS Members to Windows and Unix Servers section of this document.
If you want something other (or more) than a copy of shipped members to a Remote LIBRARY, then you can engage Post-Ship Scripts. First, understand the construct and language used when Endevor builds Package Shipping JCL.
Where is the Package Shipping JCL?
The member named C1BMXJOB in your Endevor CSIQSENU library is where it all starts, but it is only the beginning. Since there are multiple package shipping variations, the constructed JCL comes from other members of the CSIQSENU and CSIQOPTN datasets. For example, there are several #RJICPY* members in the CSIQOPTN library that are used if you use IEBCOPY at your site for copying dataset members and not FASTCOPY. The value you designate for the RJCLROOT variable on your Defaults table makes the choice for you. (If you are unsure of the right value use ‘ICPY’). If you use a value of ‘FCPY’ then the #RJFCPY* members of the CSIQOPTN library are used with package shipments.
Then, there is the choice of Transmission tool. The techdocs documentation mentions XCOM, Bulk Data Transfer, NetView File Transfer, and CONNECT:Direct. Since the command streams differ for each, they have their own set of members in the CSIQOPTN library. For example, if your transmission tool is CONNECT:Direct (aka NDM) then the content of #PS#NDM and several #PSNWDM* members are placed into your package shipping JCL.
You may create additional “Model” members to engage Post-Ship Scripts. Common reasons for your own “Model” members include the execution of remote DB2 Binds, CICS Newcopies, LLA refresh or any other automated process needed for your remote systems. Within a “Model,” you can define your own JCL steps and the conditions for which they are included.
It is a good idea to comment members that you create or touch. Place the member name into the member itself, so that you can see the line origin when you view package shipment jobs. For example here is a portion of a commented #RJICPY1 member:
&RJOBCARDS
//*----Package Shipment --------------------------------- #RJICPY1
//*------------------------------------------------------ #RJICPY1
@IF &ANY2PROCESS
//COPIES EXEC PGM=IEBCOPY #RJICPY1
//SYSPRINT DD SYSOUT=*
//SYSUT3 DD UNIT=&RUNIT,SPACE=(TRK,(5,5))
//SYSUT4 DD UNIT=&RUNIT,SPACE=(TRK,(5,5))
@ENDIF
Also recommended is the placement of members you touch into an override library, as shown in the Defining an Override Library section.
What language is this?
Package Shipping uses two languages for building its JCL
-
IBM’s Skeleton language for File Tailoring is a common language used by many applications that run on the mainframe. The syntax for members of the CSIQSENU library includes:
-
Lines that contain “)CM” in column 1 are comment lines
-
Lines that contain “)IM” followed by a member name, cause the member to be included
-
Lines that contain “)SEL” in column 1 are followed by a condition, and conditionally insert lines, until a subsequent line is found with “)ENDSEL” in column 1
-
A “Modeling” language for Endevor package shipping. As far as I know, this language is unique to package shipping and is not seen anywhere else. The syntax for members in the CSIQOPTN library includes:
-
Lines that contain “@REM” in column 1 are comment lines
-
Lines that contain “@INCLUDE=” in column 1 are followed by a member name or a single letter. These statements cause members to be included. If only a single letter appears then the letter is a suffix given to a name prefix. The prefix is a either Destination name, a name given to the Transmission method (for example #PSNWDM when using NDM), or ‘#RJNDVR’. When a member's name or a letter is enclosed in parentheses then the member is conditionally included only if it can be found.
-
Lines that contain “@IF” in column 1 are followed by a condition, and conditionally insert lines until “@ENDIF” is found in column 1. Sometimes the condition is just a variable name and is tested for a null condition. For example “@IF &DJOBDSN “ is a check to see if the variable “&DJOBDSN” has a value.
Post-Ship Scripts
Here are some reasons for using Post-Ship Scripts:
-
An output library with a last node of BINDS, contains DB2 Bind statements that must be executed at a remote site. (A Model you provide will include a step that executes the Binds)
-
An output library with a last node of CICSNEWC contains CICS Newcopy or Phasein Commands that must be executed at a remote site. (A Model you provide will include a step that executes CICS or Phasein commands)
-
An output library with a last node of COBOL contains COBOL program source that must be ADDed into Endevor at the remote site. (A Model you provide will ADD members into Endevor)
To use Post-Ship Scripts, enter the text “(SCRIPT-FILE)” into the REMOTE LIBRARY name field of a Library Mapping rule.
DISPLAY ----------------- DISPLAY DSN MAPPING RULE -------------------------
COMMAND ===>
DESTINATION:CA32A
MAPPING RULE DESCRIPTION:SYSDE32.NDVR.ADMIN.ENDEVOR.*.COBOL
To EXCLUDE datasets from being transmitted, leave REMOTE DSN blank.
For SCRIPT datasets, use the value(SCRIPT-FILE)in the REMOTE DSN.
HOST DATASET NAME: SYSDE32.NDVR.ADMIN.ENDEVOR.*.COBOL
maps to
REMOTE DATASET NAME:(SCRIPT-FILE)
Approx Host Members/Cyl:16
The “(SCRIPT-FILE)” text tells Endevor that you will provide a JCL snippet “Model” that is to be inserted into the Package Shipping JCL on conditions you define. The Reference file shows Script files a little differently. This example shows a COBOL dataset as a “Script” file.
*
SHIPMENT DATASETS
HOST LIBRARY: SYSDE32.NDVR.ADMIN.ENDEVOR.ADM1.COBOL
HOST STAGING: PUBLIC.HOST.D230404.T185145.CA66A.SH001
REMOTE STAGING: PUBLIC.RMOT.D230404.T185145.CA66A.SR001
REMOTE LIBRARY: (SCRIPT-FILE)
*
Your Script file could contain members with DB2 Bind statements.
DSN SYSTEM(DB2P)
BIND PACKAGE(PKGP2)
OWNER(OWNP2) +
QUALIFIER(QUALP) +
RETAIN VALIDATE(BIND) ISOLATION(CS) +
ACTION(REPLACE) EXPLAIN(YES) +
. . .
Or CICS Phasein commands. (Your CICS commands could look very different depending on CICS tooling).
/*VS,'F CICSPA5,CEMT SET PRO(PG000021),PHASEIN'
/*VS,'F CICSPA6,CEMT SET PRO(PG000021),PHASEIN'
/*VS,'F CICSPA7,CEMT SET PRO(PG000021),PHASEIN'
/*VS,'F CICSPA8,CEMT SET PRO(PG000021),PHASEIN'
/*VS,'F CICSPT7,CEMT SET PRO(PG000021),PHASEIN'
The last node of the Host Library name has significance in the next step. The use of descriptive and unique last nodes is recommended, for example, COBOL, DB2BINDS, and CICSPHAS. To associate the last node of a Host Library to a JCL snippet, and to indicate where to insert the snippet, see Create Model Script Steps.
Create Model Script Steps
This section covers How to build a Model Script (JCL snippet), and Where to place Model steps.
A Model Script is a JCL snippet. Package shipping supports the use of symbols, based on the Host Library's last node which enables you to specify when and where a snippet is to be inserted into the Remote Package Shipping job.
How to Build a Model Script
If the last node of a Host Library is “LASTNODE”, the Model supports language such as this.
@IF &ZZLASTNODE
. . . jcl steps when the Host Library last node is LASTNODE
// DSN=&&ZZLASTNODE
. . .
@ENDIF
The “@IF” statement tests whether the shipment includes members from a LASTNODE Host library. If true, then lines are inserted until the “@ENDIF” is encountered. The &ZZLASTNODE variable as a DSN, is replaced with a package shipment Remote Staging library name at the time of a shipment.
When the LASTNODE is COBOL. A Model might look like this.
@IF &ZZCOBOL
//*--------------------------------------------------------------------
//ADDELMS EXEC PGM=NDVRC1,DYNAMNBR=1500,PARM='C1BM3000' CA32AB
// INCLUDE MEMBER=STEPLIB <- Endevor Steplib etc
//BSTIPT01 DD *
SET STOPRC 12.
SET OPTIONS COMMENT "Shipped from DE32"
CCID "FromDE32"
***** BYPASS GENERATE PROCESSOR
OVERRIDE SIGNOUT UPDATE.
SET TO ENVIRONMENT "DEV"
SYSTEM "ESCMSNDV" SUBSYSTEM "FROMDE32" .
SET FROM DSN '&ZZCOBOL' .
ADD ELEMENT '*' TO TYPE COBOL
//C1MSGS1 DD SYSOUT=*
//C1MSGS2 DD SYSOUT=*
//*----------------------------------------------------------------------
@ENDIF
When the LASTNODE is DB2BINDS. A Model might look like this.
@IF &ZZDB2BINDS
//*--------------------------------------------------------------------
//FLATTEN EXEC PGM=IEBPTPCH
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&ZZDB2BINDS
//SYSUT2 DD DSN=WALJO11.&INPUT,
//SYSIN DD *
PUNCH TYPORG=PO,PREFORM=M,MAXFLDS=1
RECORD FIELD=(80)
//SYSUT2 DD DSN=&&BINDS,DISP=(NEW,PASS),UNIT=3390,
// DCB=(LRECL=080,RECFM=FB,DSORG=PS,BLKSIZE=0),
// SPACE=(TRK,(5,15))
//*--------------------------------------------------------------------
//BIND EXEC PGM=IKJEFT01,COND=(4,LT)
//SYSTSIN DD DSN=&&BINDS,DISP=(OLD,DELETE)
. . .
@ENDIF
IEBPTPCH is an IBM utility that can be used to “flatten” a PDS dataset. “Flattening” means all members are written concatenated into a single sequential output.
When the LASTNODE is CICSPHAS. A Model might look like this.
@IF &ZZCICSPHAS
//*--------------------------------------------------------------------
//FLATTEN EXEC PGM=IEBPTPCH
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&ZZCICSPHAS
//SYSUT2 DD DSN=WALJO11.&INPUT,
//SYSIN DD *
PUNCH TYPORG=PO,PREFORM=M,MAXFLDS=1
RECORD FIELD=(80)
//SYSUT2 DD SYSOUT=(A,INTRDR)
//*--------------------------------------------------------------------
@ENDIF
What is used at your site for Model Scripts is up to your requirements and your imagination.
Where to place Model Steps
The member #RJICPY1 (or #RJFCPY1 if using Fastcopy) is the shell for the Remote shipping job. Although you could insert your Model Steps into the #RJICPY1 or #RJFCPY1 consider these alternatives.
-
If your Model is coded specifically for one Destination, create a Model named with the Destination name (up to 7 characters) appended with a letter “B” or “A”. The final letter in the Model name indicates that it is to be inserted Before or After the IEBCOPY step of the Remote job. When the Model prefix uses the Destination name, the shipment only inserts the Model when the Destination is targeted. For example, a Model to be used only for Destination CA66 and to be inserted before the IEBCOPY should be named CA66B.
-
If your Model is applicable to all Destinations, consider inserting your Model content into the #RJNDVRB or #RJNDVRA members. You can copy the content, or use an “@INCLUDE” command, using the rules specified in a previous section named “What language is this?”.
Alternative Job Submissions
Shipment skeletons C1BMXFTP, C1BMXBD1, and C1BMXRCN, use IEBGENER to submit subsequent jobs. This method can be successful at your site, if:
- A “//*ROUTE XEQ” statement (or the JES3 equivalent) is included within the submitted JCL
- Your network configuration supports submissions of input JCL streams to execute on a remote network
As an alternative, you can replace the IEBGENER step within the skeleton with a corresponding step that runs your file transmission utility.
Destination Configuration File
If you are shipping a set of Script files to multiple destinations, and need the content of a Script file to be modified based on the Destination, then consider using a Destination Configuration File.
Suppose your DB2Bind statements are to be Shipped to two destinations, and the DB2Subsytem is different for each. Your processor can place a variable where the DB2 Subsystem names into the Scripts, such as this example.
DSN SYSTEM(&DB2SUBS)
BIND PACKAGE(PKGP2)
OWNER(OWNP2) +
QUALIFIER(QUALP) +
RETAIN VALIDATE(BIND) ISOLATION(CS) +
ACTION(REPLACE) EXPLAIN(YES) +
. . .
The Destination Configuration will cause a substitution of the variable at the time of a shipment. For example:
DESTINATION DALLAS
SYMBOL 'CISYS' VALUE 'FINANCED'
SYMBOL 'DB2SUBS' VALUE 'DSN3' .
DESTINATION ATLANTA
SYMBOL 'CISYS' VALUE 'FINATL'
SYMBOL 'DB2SUBS' VALUE 'DB2A' .
When a package is shipped to Dallas, the &DB2SUBS variable is replaced with “DSN3”
When a package is shipped to Atlanta, the &DB2SUBS variable is replaced with “DB2A”
To include a Destination Configuration File with your package shipments, complete these steps:
-
Adjust processors to write outputs that contain unresolved variables
-
Update the DESTCFGMBR parameter on the Defaults table.
-
Create the Destination Configuration (like the example above) as a member of your PARMLIB. Give values by Destination for the unresolved variables. (See Endevor Parmlib Information and find Endevor Parmlib Information)
Shipping PDS Members to Windows and Unix Servers
Here are steps you can take to ship Endevor output PDS members to a Windows or Unix Server. These steps are valid as long as your transmission tool supports transmissions to Windows and/or Unix. These tools do support such transmissions: XCOM, Connect:Direct, and SFTP.
-
Define a Local Destination for the Transmission. Local is used because there is no need to involve another remote mainframe.
-
Define Script-Files for outputs you want to ship. For example, if you want to send COBOL source, then map your COBOL file to “(SCRIPT-FILE)”.
-
Create a Script Model, named after the Destination name and the letter ‘B’.
-
Code a batch File Transmission step within the Script Model, to send the STAGE library content (for example DSN=&ZZCOBOL) to your destination Windows or Unix directory
-
You may optionally include one or more steps to make REST API calls to tools for processing the delivered members, using the zos Web Enablement Toolkit. (A future topic?).
-
Place the Script Model into an Override library.
Defining an Override Library
If you make any changes to package ship members or create new members, these recommended steps allow you to keep them active and managed by Endevor, but separated from the Endevor release datasets.
-
Create a new PDS/E library for your members. Give it a last node of OVERRIDE, for example. It highly recommended that you make the Override library be an output library in your Endevor Administration area.
-
Create a copy of C1BMXJOB. Each of the DDnames within C1BMXJOB shown below is originally coded to use only one dataset. However, each supports a concatenation of datasets. Modify references to them to reflect a concatenation with the Override library above the existing dataset already there.
-
C1BMXXCM
-
C1BMXLCM
-
C1BMXB1M
-
C1BMXBDM
-
C1BMXFTM
-
C1BMXNWM
-
C1BMXRJC
-
C1BMXMDL
-
In your Endevor startup commands - Clist, Rexx, Logon Proc, for example, place the Override library to be concatenated above the reference to the CSIQSENU library.
-
Using Endevor, place your copy of C1BMXJOB and all commented shipping members into the Override library.
How to Test Your Models and Scripts
You may want to review and test portions of your package shipping jobs without having to actually execute a shipment. Here are some steps you may follow.
-
Capture the first package Shipping job (Host job). If you defined an override library, you should see your library concatenations in the captured JCL.
-
You can follow the steps for How to Create External Package Shipment Job Streams or
-
Submit a package shipment from the Endevor panels with TYPRUN=SCAN, and capture the JCL.
-
Disable the last step(s) of the JCL. For example, you may cause subsequent Job outputs to be printed and not submitted. The first step in the Host Job is an Endevor step that copies package outputs to Host Staging libraries. What follows the first step depends on the Transmission tool. For example,
-
If the last step is an IEBGENER, change the SYSUT2 output to SYSOUT=*
-
If the last step is a Submit step using IKJFEFT01, replace it with an IEBGENER to print
-
If the last steps execute a Transmission tool, then terminate the JCL prior to those steps.
-
Save the JCL into a dataset
-
You can submit the JCL as many times as you like but you must change all occurrences of the first six characters of the time value between submissions.
-
In the job output, find references to a file name ending with.AHJOB. The content is the unsubmitted Remote Job.
-
You can submit specific steps of the job individually to validate them.
More Package Shipping Choices
Other Considerations for Package Shipping and Post-Ship Scripts:
-
Shipping considerations for Promotion packages
-
The Ship Asis feature
-
An ENCOPTBL entry selects the user ID to be used for package shipments. See the PACKAGE_SHIP_WITH_ALTID option. If Set ‘ON’, then package shipment jobs are submitted under the Endevor Alternate ID. Otherwise, shipment jobs are submitted under the requestor’s ID.
-
Package Shipments can be automated, such that the content of a package determines if and where to automate package shipments. There are two existing methods:
-
Package Automation - using an Endevor exit to automate package shipping
-
Automate CA Endevor Package Shipments with Zowe CLI - using a Zowe command to automate package shipping.
-
Other transmission methods can be successfully used with Package Shipping. For example, both CyberFusion and IBM’s SFTP have been successfully configured for package shipping.
-
Most of this document describes Shipping to Remote Destinations, but valid for Local Shipments too.
Other considerations for Packages in general:
-
Shipment Confirmation Email Notification
-
Package Approvals Made Easy
-
Endevor package Integration with Service-Now
Conclusion
In summary, you can see that package shipping is a very robust and versatile feature of Endevor. If you have comments or questions you can post them here, or just drop a note to joseph.walther@broadcom.com.