Appendix
NOTE: In the summary section of the sysout, you can tell which elements contained the search string because they will have a number (for the number of matches found) in the far right column - SCL WRITTEN. You can then go back to that section of the scan and find the lines where a match was found.
If you need to scan for many search strings across many Endevor systems (ACES, SUBRO, etc.), take a copy of OTXX94.ENDEVOR.SCANS(SCANALF) and edit it to meet your needs.
- The first statement is a "SET WHERE TEXT" statement that lists all the strings to be searched for. This "WHERE" statement is in effect for each "LIST" statement that follows.
- Next is the "SET OPTIONS" statement. Leave this as is. the "SHOW TEXT" clause causes the scan to show the lines where the search string is found which is necessary if you're searching for more than one string.
- Use the "LIST" statements to search many elements (by using a wildcard) of a particular type in an Endevor system.
In order to submit this SCL, go into Endevor Batch option (3) and specify your dataset in the REQUEST DATA SET section. Use option 3 to submit the scan, make sure the jobname is OTXX94# and that the MSGCLASS on the job card is J for $AVRS. The sysout will show only those elements where one of the search strings was found.
===> //OTXX94# JOB (44001,FS01,00000,1111),'PROJECT C583', => PROJECT NAME
===> // CLASS=A,MSGCLASS=J,NOTIFY=OT???? => YOUR ID
===> //*
===> //*$AVRS C=OTCACTSD =>(comment what program/linkcard/binddeck/sysin)
It's very important to use the proper project number in the jobcard, comment the project name in the comment field of the jobcard, notify your ID of job completion and use the $AVRS C= command to comment on what element you are adding/re-compiling/copying back...etc
Custom Search
ENDEVOR SCANS
SCANS
1. From the Endevor Primary Options Menu, select 3 - BATCH.
(ENTER KEY).
2. Enter Option 1 - BUILD SCL.
Enter the name of the Request Data Set, e.g., OTXX94.LIB.CNTL(LIST).
Enter any job card changes needed.
(ENTER KEY).
3. Enter Option 11 - LIST ELEMENT.
(ENTER KEY).
4. Enter Option L - LIST element action.
Enter the FROM ENDEVOR INFO search criteria.
Enter the LIST OPTIONS criteria.
Note: Enter N in the Display List and Endevor selects and searches
all elements that fit the criteria entered in the FROM ENDEVOR INFO;
Enter Y in Display List and Endevor displays all
elements that fit the criteria entered in the FROM ENDEVOR INFO,
so that you must indicate which elements you wish to search, by
placing an L next to the member(s) to be included.
Enter the TEXT STRING to be scanned. (ENTER KEY).
5. A confirmation screen appears, listing the number of elements that were
selected for processing. Press the (ENTER KEY) to continue.
6. The message "SCL generated" appears, and Endevor displays the LIST ELEMENT ACTION screen.
7, Back out of the LIST ELEMENT ACTION screen.
(PF3 KEY).
8. Back out of the SCL GENERATION screen.
(PF3 KEY).
9. Select Option 3 - SUBMIT from the BATCH OPTIONS MENU screen.
(A batch job runs the scan.)
(ENTER KEY).
10. Once the batch job is completed, you can view the results in $AVRS. All elements
searched are listed on the output. If no match was found, the message is
'ELEMENT(S) BYPASSED, FAILED TO SATISFY "WHERE" CLAUSE'. If a match was found,
the element name and all the lines where a match was found are listed.
1. From the Endevor Primary Options Menu, select 3 - BATCH.
(ENTER KEY).
2. Enter Option 1 - BUILD SCL.
Enter the name of the Request Data Set, e.g., OTXX94.LIB.CNTL(LIST).
Enter any job card changes needed.
(ENTER KEY).
3. Enter Option 11 - LIST ELEMENT.
(ENTER KEY).
4. Enter Option L - LIST element action.
Enter the FROM ENDEVOR INFO search criteria.
Enter the LIST OPTIONS criteria.
Note: Enter N in the Display List and Endevor selects and searches
all elements that fit the criteria entered in the FROM ENDEVOR INFO;
Enter Y in Display List and Endevor displays all
elements that fit the criteria entered in the FROM ENDEVOR INFO,
so that you must indicate which elements you wish to search, by
placing an L next to the member(s) to be included.
Enter the TEXT STRING to be scanned. (ENTER KEY).
5. A confirmation screen appears, listing the number of elements that were
selected for processing. Press the (ENTER KEY) to continue.
6. The message "SCL generated" appears, and Endevor displays the LIST ELEMENT ACTION screen.
7, Back out of the LIST ELEMENT ACTION screen.
(PF3 KEY).
8. Back out of the SCL GENERATION screen.
(PF3 KEY).
9. Select Option 3 - SUBMIT from the BATCH OPTIONS MENU screen.
(A batch job runs the scan.)
(ENTER KEY).
10. Once the batch job is completed, you can view the results in $AVRS. All elements
searched are listed on the output. If no match was found, the message is
'ELEMENT(S) BYPASSED, FAILED TO SATISFY "WHERE" CLAUSE'. If a match was found,
the element name and all the lines where a match was found are listed.
ENDEVOR NOTIFICATIONS
NOTIFICATIONS
When your manager Receives/Reviews/Assigns a PROJECT:
1) The PROJECT Requestor
2) PROJECT Requestor's Supervisor
3) PMSO (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
4) The Analyst to which the PROJECT is assigned
5) Business Market (for STAT Changes)
Personal Market (for STAT Changes)
When you start to work on a PROJECT, please notify the following people
to set Client TESTING and PRODUCTION implementation dates:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
4) PMSO (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
5) ACES on-call employees, Manager - IS
6) Business Market for STAT Changes
Personal Markets for STAT Changes
7) Look at Palinfo-Admin-Endevor-CHGNOTFY.XLS. There are several other groups that
must be notified if we make changes in ACES to certain designated programs. The
SCREEN CHANGE NOTIFICATION EXCEL Spreadsheet will identify the programs, that if
changed, will impact other groups, and who should be notified. The Project
Leader should contact these other groups at the very beginning of the project to
ensure that they have the appropriate time needed to make any necessary changes.
When you have completed your System Testing, please notify the following people:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
4) On-call employees, Manager - IS
When Claims Systems completes their Client TESTING, clients should notify:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
3) Individual PMSO contact (Personal Market Support Operations)
4) Individual RSIP contact (Risk Service Information Processes)
5) On-call employees, Manager - IS
A couple of days before the Production Implementation, please notify:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
4) PMSO (Personal Market Support Operations)
(Risk Service Information Processes)
5) ACES Manager - IS and ACES SR. I/S Assistant (All changes)
6) Individual contact for Business Market changes
7) Individual contact for Personal Market changes
When your manager Receives/Reviews/Assigns a PROJECT:
1) The PROJECT Requestor
2) PROJECT Requestor's Supervisor
3) PMSO (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
4) The Analyst to which the PROJECT is assigned
5) Business Market (for STAT Changes)
Personal Market (for STAT Changes)
When you start to work on a PROJECT, please notify the following people
to set Client TESTING and PRODUCTION implementation dates:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
4) PMSO (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
5) ACES on-call employees, Manager - IS
6) Business Market for STAT Changes
Personal Markets for STAT Changes
7) Look at Palinfo-Admin-Endevor-CHGNOTFY.XLS. There are several other groups that
must be notified if we make changes in ACES to certain designated programs. The
SCREEN CHANGE NOTIFICATION EXCEL Spreadsheet will identify the programs, that if
changed, will impact other groups, and who should be notified. The Project
Leader should contact these other groups at the very beginning of the project to
ensure that they have the appropriate time needed to make any necessary changes.
When you have completed your System Testing, please notify the following people:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project (Personal Market Support Operations)
RSIP (Risk Service Information Processes)
4) On-call employees, Manager - IS
When Claims Systems completes their Client TESTING, clients should notify:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
3) Individual PMSO contact (Personal Market Support Operations)
4) Individual RSIP contact (Risk Service Information Processes)
5) On-call employees, Manager - IS
A couple of days before the Production Implementation, please notify:
1) The PROJECT Requestor
2) The PROJECT Requestor's Supervisor
3) Your Project Leader
4) PMSO (Personal Market Support Operations)
(Risk Service Information Processes)
5) ACES Manager - IS and ACES SR. I/S Assistant (All changes)
6) Individual contact for Business Market changes
7) Individual contact for Personal Market changes
ENDEVOR BATCH (cont'd)
BATCH (cont'd)
• If a proc that is part of the CA7 test cycle was changed to point to test versions of sysins, load modules, etc., that have subsequently been implemented into production, change the SYS1.PRODPROC member as needed to access the production components.
• If a new job was either added or had a scheduling change, update the constellation in PAL INFO/Hotbook/ACES Constellation
• If a new ISOT job was either added or had a change in the purpose, frequency or scheduling dependencies, update the document SERVER/PAL INFO/SUPPLEMENTAL HOTBOOK /ISOTLST.DOC.
• If a new batch program has been added, update the Batch Program Listing for new programs Pal Info \ Listprogdesc \Batchcbl.XLS.
• Delete proc member from signout document located in the current implementation folder.
• If a program results in an update, insert or delete to a propagated database or DB2 Table, update the DPROP Batch System Profile in Pal Info \ ACES \ Propagation Profile \ BTCHPROF.XLS.
ON-LINE
• Delete program from TDF if it was imported in.
• Cleanup your own libraries of MFS source code, format and referral members.
• If you had MFS changes, delete the format and referal members from IMSVSH.TFORMAT and IMSVSH.TREFERAL, using Aces panel Q.10 (option 5). Create the format and referal members for new MFS in 'OTXX94.TELON21.TFORMAT' and 'OTXX94.TELON21.TREFERAL' (used for BTS testing). Delete the OX version of the MFS source (used for the X system) from BATCH.PANLIB.
• Change IMST link map to refer back to the prod. library using Aces panel Q.7.11.2.
• SAVED FOR FUTURE INSTRUCTIONS REGARDING XPEDITER
• Run the IMST link using the production OBJ's using Aces panel Q.11.3.
• Run the IMST bind using Aces panel Q.14.1
• If a program change results in an update, insert or delete to a propagated Database or DB2 Table, update the DPROP Online System Profile in Pal Info \ ACES \ Propagation Profile \ ONLNPROF.XLS
• If a new online program has been added, update the Link group Document PAL INFO/
List Prog/ DESC/ Linkgrp.doc
• If a proc that is part of the CA7 test cycle was changed to point to test versions of sysins, load modules, etc., that have subsequently been implemented into production, change the SYS1.PRODPROC member as needed to access the production components.
• If a new job was either added or had a scheduling change, update the constellation in PAL INFO/Hotbook/ACES Constellation
• If a new ISOT job was either added or had a change in the purpose, frequency or scheduling dependencies, update the document SERVER/PAL INFO/SUPPLEMENTAL HOTBOOK /ISOTLST.DOC.
• If a new batch program has been added, update the Batch Program Listing for new programs Pal Info \ Listprogdesc \Batchcbl.XLS.
• Delete proc member from signout document located in the current implementation folder.
• If a program results in an update, insert or delete to a propagated database or DB2 Table, update the DPROP Batch System Profile in Pal Info \ ACES \ Propagation Profile \ BTCHPROF.XLS.
ON-LINE
• Delete program from TDF if it was imported in.
• Cleanup your own libraries of MFS source code, format and referral members.
• If you had MFS changes, delete the format and referal members from IMSVSH.TFORMAT and IMSVSH.TREFERAL, using Aces panel Q.10 (option 5). Create the format and referal members for new MFS in 'OTXX94.TELON21.TFORMAT' and 'OTXX94.TELON21.TREFERAL' (used for BTS testing). Delete the OX version of the MFS source (used for the X system) from BATCH.PANLIB.
• Change IMST link map to refer back to the prod. library using Aces panel Q.7.11.2.
• SAVED FOR FUTURE INSTRUCTIONS REGARDING XPEDITER
• Run the IMST link using the production OBJ's using Aces panel Q.11.3.
• Run the IMST bind using Aces panel Q.14.1
• If a program change results in an update, insert or delete to a propagated Database or DB2 Table, update the DPROP Online System Profile in Pal Info \ ACES \ Propagation Profile \ ONLNPROF.XLS
• If a new online program has been added, update the Link group Document PAL INFO/
List Prog/ DESC/ Linkgrp.doc
ENDEVOR BATCH
BATCH
• Ensure that the first two datasets in the STEPLIB DD of the test procedure are
//STEPLIB DD DSN=BATCH.OT.END.LOADLIB,DISP=SHR
// DD DSN=OTXX94.JOBLIBT,DISP=SHR
// DD DSN=PROD.OT.END.LOADLIB,DISP=SHR
If you have changed a dynamic subprogram, this will need to be done for all main programs calling this common subprogram dynamically.
If the test jcl procedure has not been set up this way, please change it and move the changed version to SYSTM1.ENDEVOR.PRODPROC.
• This following is for the test IKJEFT01 - SYSTSIN member only.
If the program is DB2 only running under IKJEFT01, change the SYSTSIN DD member in SYS1.JOBSYSIN from the old format
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH) PLAN(OTRDCATH) LIB('OTXX94.JOBLIBT')
END
to a new format (if the plan name is the same as program name)
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH)
END
or (if the plan name is different from the program name)
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH) PLAN(OTXXXXXX)
END
• Delete the load from OTXX94.JOBLIBT (except for OTDPIMSP, OTDPDB2P, OTDB2CLM, and OTPOOL).
• If your program uses a link group, change IMST link map to refer back to the production library using Acespanel Q.7.11.10. Run the IMST link using the production OBJ's using Aces panel Q.11.4.
• Run a test bind to create the test plan using the production DBRM.
• Note: For procs that are part of the ACES CA7 test cycle, the following two
steps may already have occurred. See the 'Batch Change Checklist' document
for further clarification.
1) For any new sysin members where the Production and IMST version will be
different (i.e. the mailnote recipients), add the IMST version to SYS1.JOBSYSIN.
Make sure the IMST proc points to SYS1.JOBSYIN.
2) Move all the IMST procs to SYS1.PRODPROC.
• Ensure that the first two datasets in the STEPLIB DD of the test procedure are
//STEPLIB DD DSN=BATCH.OT.END.LOADLIB,DISP=SHR
// DD DSN=OTXX94.JOBLIBT,DISP=SHR
// DD DSN=PROD.OT.END.LOADLIB,DISP=SHR
If you have changed a dynamic subprogram, this will need to be done for all main programs calling this common subprogram dynamically.
If the test jcl procedure has not been set up this way, please change it and move the changed version to SYSTM1.ENDEVOR.PRODPROC.
• This following is for the test IKJEFT01 - SYSTSIN member only.
If the program is DB2 only running under IKJEFT01, change the SYSTSIN DD member in SYS1.JOBSYSIN from the old format
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH) PLAN(OTRDCATH) LIB('OTXX94.JOBLIBT')
END
to a new format (if the plan name is the same as program name)
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH)
END
or (if the plan name is different from the program name)
DSN SYSTEM(DB2T)
RUN PROGRAM(OTRDCATH) PLAN(OTXXXXXX)
END
• Delete the load from OTXX94.JOBLIBT (except for OTDPIMSP, OTDPDB2P, OTDB2CLM, and OTPOOL).
• If your program uses a link group, change IMST link map to refer back to the production library using Acespanel Q.7.11.10. Run the IMST link using the production OBJ's using Aces panel Q.11.4.
• Run a test bind to create the test plan using the production DBRM.
• Note: For procs that are part of the ACES CA7 test cycle, the following two
steps may already have occurred. See the 'Batch Change Checklist' document
for further clarification.
1) For any new sysin members where the Production and IMST version will be
different (i.e. the mailnote recipients), add the IMST version to SYS1.JOBSYSIN.
Make sure the IMST proc points to SYS1.JOBSYIN.
2) Move all the IMST procs to SYS1.PRODPROC.
ENDEVOR MISCELLANEOUS CLEANUP WORK
MISCELLANEOUS CLEANUP WORK
Even if a system is in Endevor, you will still do development and testing outside of Endevor, therefore, it is still necessary to do this cleanup work.
COMMON(BATCH & ON-LINE)
• Delete any copybooks that went into production from 'OTXX94.COPYLIB.DATA'
Delete copylib member from located in the current implementation folder.
• Cleanup your own libraries of Source code, Copybooks, and DBRMS.
• If program has db2, delete any related DBRM's from 'OTXX94.LIB.DBRM'. OTDPIMSP, OTDPDB2P, OTDB2CLM, OTNICADP, and OTPOOL are the execptions to this rule. They are subprograms that get compiled/linked into both 'OTXX94.JOBLIBT' and 'PROD.OT.IMSLOADT' and bound into plans used by many link groups. If these members get deleted from the test DBRM library you will get a -818 timestamp error in any program accessing them. This is because the bind is using the production DBRM and the object module used to create the load member will still be the one from the last IMST compile/link. Therefore the timestamps in the OBJ and DBRM do not match, resulting in a DB2 return code of -818. Hence, don't delete these DBRMS (also, don't delete these load modules from 'OTXX94.JOBLIBT and 'PROD.OT.IMSLOADT').
• If a PSB was used in a new program or added to an existing program, update the PSB cross reference DB2 table, BATCHBOT.OTXPSBXT, with the production PSB information.
• Cleanup $avers after you get your jobs back. Be sure that all T, X and P jobs are deleted.
• If a new bind was either added or revised to use the IMS exit program or the DB2 exit program, update the DPROP Users Guide document by adding the bind to the List of Binds For IMS and DB2 Propagation under Nifty Things To Know in SERVER/PAL INFO/OVERVIEW/DPROP
• If a new bind was created, refer to Section XIII DB2 PROCEDURES Step D.
• If a new Follow-UP note was created, update the following documents:
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/PGMTRACK.XLS
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/WORKFLOW.XLS
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/SEG VALUES.XLS
• If a new DB2 table, Database, ACES Table (TMS), Cobra File or Property File created update.
PAL INFO\DATABASE\ACES DATABASE & TMS SUMMARY
Even if a system is in Endevor, you will still do development and testing outside of Endevor, therefore, it is still necessary to do this cleanup work.
COMMON(BATCH & ON-LINE)
• Delete any copybooks that went into production from 'OTXX94.COPYLIB.DATA'
Delete copylib member from located in the current implementation folder.
• Cleanup your own libraries of Source code, Copybooks, and DBRMS.
• If program has db2, delete any related DBRM's from 'OTXX94.LIB.DBRM'. OTDPIMSP, OTDPDB2P, OTDB2CLM, OTNICADP, and OTPOOL are the execptions to this rule. They are subprograms that get compiled/linked into both 'OTXX94.JOBLIBT' and 'PROD.OT.IMSLOADT' and bound into plans used by many link groups. If these members get deleted from the test DBRM library you will get a -818 timestamp error in any program accessing them. This is because the bind is using the production DBRM and the object module used to create the load member will still be the one from the last IMST compile/link. Therefore the timestamps in the OBJ and DBRM do not match, resulting in a DB2 return code of -818. Hence, don't delete these DBRMS (also, don't delete these load modules from 'OTXX94.JOBLIBT and 'PROD.OT.IMSLOADT').
• If a PSB was used in a new program or added to an existing program, update the PSB cross reference DB2 table, BATCHBOT.OTXPSBXT, with the production PSB information.
• Cleanup $avers after you get your jobs back. Be sure that all T, X and P jobs are deleted.
• If a new bind was either added or revised to use the IMS exit program or the DB2 exit program, update the DPROP Users Guide document by adding the bind to the List of Binds For IMS and DB2 Propagation under Nifty Things To Know in SERVER/PAL INFO/OVERVIEW/DPROP
• If a new bind was created, refer to Section XIII DB2 PROCEDURES Step D.
• If a new Follow-UP note was created, update the following documents:
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/PGMTRACK.XLS
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/WORKFLOW.XLS
SERVER/PAL INFO/OVERVIEW/FOLLOWUP/SEG VALUES.XLS
• If a new DB2 table, Database, ACES Table (TMS), Cobra File or Property File created update.
PAL INFO\DATABASE\ACES DATABASE & TMS SUMMARY
ENDEVOR EMERGENCY BATCH PRODUCTION UPDATES
EMERGENCY BATCH PRODUCTION UPDATES
NOTE: These procedures are different because normally at night you will not have 2 Endevor approvers. So you will have to force the change to execute outside of Endevor and put it into Endevor the next day, if necessary.
If you are forcing a program into production at night here are some
things to remember/consider:
1. Compile the program using Q.2.1 specifying your own TSO library names
2. Check the job to be sure that it compiled clean. If necessary run a test if you have to on SYSC
3. Copy the appropriate binddeck needed to PROD.OT.PRODBIND
4. Edit the binddeck to point to your own TSO DBRM library name from the compile. You should place your dataset name ABOVE the PROD.OT.END.DBRMLIB and there should not be any other members in your library
5. Edit the job OTXX94.SYSG.DB2.CNTL(BIND).
6. Change the notify parameter to the ID that you are logged onto
7. Make sure it says XEQ NJEG to run on system G
8. Make sure the first exec statement is NOT commented (should be PROD.OT.PRODBIND) and the second exec statement IS commented (should be PROD.OT.PRODBBND).
9. Submit the job OTXX94.SYSG.DB2.CNTL(BIND) on system G.
10. Check the job in $avers to make sure the bind was successful.
11. Copy the related PROD proc to SYSTM1.ENDEVOR.TESTPROC and concatenate your TSO load dataset, defined in the compile, above the PROD.OT.END.LOADLIB. It is best to keep this module isolated therefore it needs to be the only one in your TSO load library.
12. Call the operator and ask them to restart the job with a step/restart if necessary.
NOTE: These procedures are different because normally at night you will not have 2 Endevor approvers. So you will have to force the change to execute outside of Endevor and put it into Endevor the next day, if necessary.
If you are forcing a program into production at night here are some
things to remember/consider:
1. Compile the program using Q.2.1 specifying your own TSO library names
2. Check the job to be sure that it compiled clean. If necessary run a test if you have to on SYSC
3. Copy the appropriate binddeck needed to PROD.OT.PRODBIND
4. Edit the binddeck to point to your own TSO DBRM library name from the compile. You should place your dataset name ABOVE the PROD.OT.END.DBRMLIB and there should not be any other members in your library
5. Edit the job OTXX94.SYSG.DB2.CNTL(BIND).
6. Change the notify parameter to the ID that you are logged onto
7. Make sure it says XEQ NJEG to run on system G
8. Make sure the first exec statement is NOT commented (should be PROD.OT.PRODBIND) and the second exec statement IS commented (should be PROD.OT.PRODBBND).
9. Submit the job OTXX94.SYSG.DB2.CNTL(BIND) on system G.
10. Check the job in $avers to make sure the bind was successful.
11. Copy the related PROD proc to SYSTM1.ENDEVOR.TESTPROC and concatenate your TSO load dataset, defined in the compile, above the PROD.OT.END.LOADLIB. It is best to keep this module isolated therefore it needs to be the only one in your TSO load library.
12. Call the operator and ask them to restart the job with a step/restart if necessary.
ENDEVOR EMERGENCY ONLINE PRODUCTION UPDATES
EMERGENCY ONLINE PRODUCTION UPDATES
If you are forcing a program into production during the day here are some
things to remember/consider:
1. Do you need to turn off screens? Stop transactions? Notify
Claims Systems/ACES-FSS-NCC Help desks/Tom Jost/Stat/Financial/Technical team?
2. Add the program to Endevor stage 1
3. Generate the linkcard using COPYBACK=Y
4. Move the element(s) to Endevor stage 2
5. Have Operations demand into CA7 OTONLNCP and/or OTBTCHCP and/or OTDBRMCP WITH OUT TRIGGERS to copy the members from the stage 2 libraries to production. Make sure yours are the only members in the stage 2 libraries first.
6. Run OTD2BIND and/or OTD2BBND WITHOUT TRIGGERS if necessary with the appropriate bind reset job following it. OTBINDRP follows OTD2BIND, OTBBNDRP
follows OTD2BBND - WITHOUT TRIGGERS.
7. Verify the MFS on all systems
8. Have IMS refresh the LLA & regions (BE SURE TO SPECIFY G & A)
NOTE: There is a timing issue between the bind and region refresh. If the new bind is done and the region refresh is not done right away, the load module will be out of sync with the application plan(s) and a -818 may occur. Similarly, if the region refresh is done and the bind is not done right away, the application plan(s) will be out of sync with the new load module and a -818 may occur.
9. Turn on screens, start transactions, test, notify the above
NOTE: MFS should NOT be forced in at all costs.
If you are forcing a program into production during the day here are some
things to remember/consider:
1. Do you need to turn off screens? Stop transactions? Notify
Claims Systems/ACES-FSS-NCC Help desks/Tom Jost/Stat/Financial/Technical team?
2. Add the program to Endevor stage 1
3. Generate the linkcard using COPYBACK=Y
4. Move the element(s) to Endevor stage 2
5. Have Operations demand into CA7 OTONLNCP and/or OTBTCHCP and/or OTDBRMCP WITH OUT TRIGGERS to copy the members from the stage 2 libraries to production. Make sure yours are the only members in the stage 2 libraries first.
6. Run OTD2BIND and/or OTD2BBND WITHOUT TRIGGERS if necessary with the appropriate bind reset job following it. OTBINDRP follows OTD2BIND, OTBBNDRP
follows OTD2BBND - WITHOUT TRIGGERS.
7. Verify the MFS on all systems
8. Have IMS refresh the LLA & regions (BE SURE TO SPECIFY G & A)
NOTE: There is a timing issue between the bind and region refresh. If the new bind is done and the region refresh is not done right away, the load module will be out of sync with the application plan(s) and a -818 may occur. Similarly, if the region refresh is done and the bind is not done right away, the application plan(s) will be out of sync with the new load module and a -818 may occur.
9. Turn on screens, start transactions, test, notify the above
NOTE: MFS should NOT be forced in at all costs.
ENDEVOR BACKUP LINKS
BACKUP LINKS
Whenever and element (COBOL, TELON, LINKCARD) is moved to Endevor stage 2 through a package, backups are done automatically by the move processor attached to the element. The backups are done as follows:
ELEMENT BACKUPS TAKEN
Batch non-DB2 (standalone link) LOAD
Batch DB2 (standalone link) DBRM, LOAD
Online non-DB2 no backup taken
Online DB2 DBRM
Online Link LOAD
The backups are made from the previous version of the member in the production library as follows:
PRODUCTION LIBRARY BACKUP LIBRARY
PROD.OT.END.LOADLIB PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.IMSLOAD PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.DBRMLIB PROD.OT.END.DBRMLIB.BACKUP
XV. RESTORING PRODUCTION LOAD MODULES FROM BACK-UP
IT IS VERY IMPORTANT THAT YOU NOTIFY YOUR PROJECT LEADER AND/OR A MEMBER OF THE TECHNICAL TEAM BEFORE ATTEMPTING TO RESTORE FROM BACK-UP. THEY WILL BE ABLE TO ASSIST YOU AND MAKE SURE THAT A RESTORE IS NEEDED. ALWAYS CONSULT YOUR ANALYST AND/OR THE TECHNICAL TEAM BEFORE RESTORING FROM BACK-UP. THE SYSTEM MANAGER SHOULD ALSO BE NOTIFIED.
At this point, our backout procedures are still manual. We have looked into the Endevor backout, however, it only works if you are backing out your changes the same day you put them in and the elements are sitting in the stage 2 libraries. Once they have been moved to the production libraries, the Endevor backout does not work.
If your restore is not an emergency, you do not have to run the special jobs described below to copy the members from the backup libraries to the production libraries. In this case, you may simply follow the cleanup procedures outlined in step 6 to recompile/relink/move to stage 2.
NOTE: If an MFS change had been made you cannot use these procedures to restore from back-up. You will have to get together with your project leader and work out a solution.
1. Before attempting restore, it may be a good idea to save a copy of the existing production module. This will allow you to return to it if the module was needlessly restored.
2. Find the back-up files you have to restore. The back-up files are in the libraries:
PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.DBRMLIB.BACKUP
NOTES:
All our systems, ACES, URS, Subro, FRACS, and Notes are backed up to these "OT" libraries.
The load modules that are copied to both the batch and online load library by the processor CIANBL47 are backed up only to PROD.OT.END.LOADLIB.BACKUP.
3. You will submit special jobs in order to copy the backed up members to the production libraries. There are jobsysin members (outside of Endevor) that you must update with the members you wish to restore.
The procs are in SYS1.PRODPROC; the jobsysins are in SYS1.JOBSYSIN; the jobs are in OTXX94.SPECIAL.JOBS. The names are as follows:
OTBKOLLD - Edit this jobsysin and run this job to restore online load modules.
OTBKBCLD - Edit this jobsysin and run this job to restore batch load modules.
OTBKDBRM - Edit this jobsysin and run this job to restore dbrms.
Once the job(s) run, check the newly copied members in the production libraries.
Remember that the new online modules will not appear until the LLA has been refreshed. See step 5 below.
4. A special bind job will have to be run if the module you are restoring has DB2 in it. You must copy the production binddeck to the dataset PROD.OT.PRODBIND. Be sure your entry is the only entry in the prodbind dataset. If it is not you will have to copy the other(s) to another dataset, run your special bind and then replace the previous entries after you run this special bind. The JCL to run this bind can be found in OTXX94.SYSG.DB2.CNTL(BIND). (The only thing that may need to be changed in this JCL is possibly the job name on the jobcard and the notify. It needs to run on G). Check the control cards before submitting the job. Check the job once it ends. The production binddecks for our systems are in the following libraries:
ACES - PROD.OT.END.BINDDECK
SUBRO - PROD.SU.END.BINDDECK Mudetail, Notes and URS have no DB2.
FRACS - PROD.FS.END.BINDDECK
ALF - PROD.OJ.LF.END.BINDDECK
NOTE: There is a timing issue between the bind and region refresh. If the new bind is done and the region refresh is not done right away, the load module will be out of sync with the application plan(s) and a -818 may occur. Similarly, if the region refresh is done and the bind is not done right away, the application plan(s) will be out of sync with the new load module and a -818 may occur.
5. For online restores call the TP room and have the production region refreshed and also an LLA refresh if the load library is under LLA control. You can check for LLA control by issuing a LISTQ command on system G against the PROD.OT.END.IMSLOAD library. If it is under LLA control the LISTQ will tell you that the library is in use by LLA.
The production regions are:
APPLICATIONS W/ TRANSACTIONS
SYSTEM EXECUTING IN REGION REGION
SYSTEM A ACES/FRACS/URS IMCLIFE1
IMCLIFE2
IMCLIFE3
SYSTEM G ACES/SUBRO/ADD CLAIM/NOTES/ALF/MUDETAIL
IF ANY OF THESE SYSTEMS REQUIRE A REGION REFRESH, REQUEST ALL OF SYSTEM G TO BE REFRESHED.
6. Cleanup - you may follow the procedures outlined above to quickly restore your systems to their previous state. However, it is important that all the pieces are in sync. It is important that we do not leave the "bad" source as the latest level in Endevor. As part of the cleanup, you should retrieve the previous version of source that you want to restore and add it back to Endevor using the procedures outlined in section V. This will create a new level of the element reflecting what is currently in production. If the element is associated with a link group, you must also re-link using the procedures outlined in section VII for linking an existing linkcard. You will then move the source and linkcard element(s) to stage 2 via a package.
Whenever and element (COBOL, TELON, LINKCARD) is moved to Endevor stage 2 through a package, backups are done automatically by the move processor attached to the element. The backups are done as follows:
ELEMENT BACKUPS TAKEN
Batch non-DB2 (standalone link) LOAD
Batch DB2 (standalone link) DBRM, LOAD
Online non-DB2 no backup taken
Online DB2 DBRM
Online Link LOAD
The backups are made from the previous version of the member in the production library as follows:
PRODUCTION LIBRARY BACKUP LIBRARY
PROD.OT.END.LOADLIB PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.IMSLOAD PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.DBRMLIB PROD.OT.END.DBRMLIB.BACKUP
XV. RESTORING PRODUCTION LOAD MODULES FROM BACK-UP
IT IS VERY IMPORTANT THAT YOU NOTIFY YOUR PROJECT LEADER AND/OR A MEMBER OF THE TECHNICAL TEAM BEFORE ATTEMPTING TO RESTORE FROM BACK-UP. THEY WILL BE ABLE TO ASSIST YOU AND MAKE SURE THAT A RESTORE IS NEEDED. ALWAYS CONSULT YOUR ANALYST AND/OR THE TECHNICAL TEAM BEFORE RESTORING FROM BACK-UP. THE SYSTEM MANAGER SHOULD ALSO BE NOTIFIED.
At this point, our backout procedures are still manual. We have looked into the Endevor backout, however, it only works if you are backing out your changes the same day you put them in and the elements are sitting in the stage 2 libraries. Once they have been moved to the production libraries, the Endevor backout does not work.
If your restore is not an emergency, you do not have to run the special jobs described below to copy the members from the backup libraries to the production libraries. In this case, you may simply follow the cleanup procedures outlined in step 6 to recompile/relink/move to stage 2.
NOTE: If an MFS change had been made you cannot use these procedures to restore from back-up. You will have to get together with your project leader and work out a solution.
1. Before attempting restore, it may be a good idea to save a copy of the existing production module. This will allow you to return to it if the module was needlessly restored.
2. Find the back-up files you have to restore. The back-up files are in the libraries:
PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.DBRMLIB.BACKUP
NOTES:
All our systems, ACES, URS, Subro, FRACS, and Notes are backed up to these "OT" libraries.
The load modules that are copied to both the batch and online load library by the processor CIANBL47 are backed up only to PROD.OT.END.LOADLIB.BACKUP.
3. You will submit special jobs in order to copy the backed up members to the production libraries. There are jobsysin members (outside of Endevor) that you must update with the members you wish to restore.
The procs are in SYS1.PRODPROC; the jobsysins are in SYS1.JOBSYSIN; the jobs are in OTXX94.SPECIAL.JOBS. The names are as follows:
OTBKOLLD - Edit this jobsysin and run this job to restore online load modules.
OTBKBCLD - Edit this jobsysin and run this job to restore batch load modules.
OTBKDBRM - Edit this jobsysin and run this job to restore dbrms.
Once the job(s) run, check the newly copied members in the production libraries.
Remember that the new online modules will not appear until the LLA has been refreshed. See step 5 below.
4. A special bind job will have to be run if the module you are restoring has DB2 in it. You must copy the production binddeck to the dataset PROD.OT.PRODBIND. Be sure your entry is the only entry in the prodbind dataset. If it is not you will have to copy the other(s) to another dataset, run your special bind and then replace the previous entries after you run this special bind. The JCL to run this bind can be found in OTXX94.SYSG.DB2.CNTL(BIND). (The only thing that may need to be changed in this JCL is possibly the job name on the jobcard and the notify. It needs to run on G). Check the control cards before submitting the job. Check the job once it ends. The production binddecks for our systems are in the following libraries:
ACES - PROD.OT.END.BINDDECK
SUBRO - PROD.SU.END.BINDDECK Mudetail, Notes and URS have no DB2.
FRACS - PROD.FS.END.BINDDECK
ALF - PROD.OJ.LF.END.BINDDECK
NOTE: There is a timing issue between the bind and region refresh. If the new bind is done and the region refresh is not done right away, the load module will be out of sync with the application plan(s) and a -818 may occur. Similarly, if the region refresh is done and the bind is not done right away, the application plan(s) will be out of sync with the new load module and a -818 may occur.
5. For online restores call the TP room and have the production region refreshed and also an LLA refresh if the load library is under LLA control. You can check for LLA control by issuing a LISTQ command on system G against the PROD.OT.END.IMSLOAD library. If it is under LLA control the LISTQ will tell you that the library is in use by LLA.
The production regions are:
APPLICATIONS W/ TRANSACTIONS
SYSTEM EXECUTING IN REGION REGION
SYSTEM A ACES/FRACS/URS IMCLIFE1
IMCLIFE2
IMCLIFE3
SYSTEM G ACES/SUBRO/ADD CLAIM/NOTES/ALF/MUDETAIL
IF ANY OF THESE SYSTEMS REQUIRE A REGION REFRESH, REQUEST ALL OF SYSTEM G TO BE REFRESHED.
6. Cleanup - you may follow the procedures outlined above to quickly restore your systems to their previous state. However, it is important that all the pieces are in sync. It is important that we do not leave the "bad" source as the latest level in Endevor. As part of the cleanup, you should retrieve the previous version of source that you want to restore and add it back to Endevor using the procedures outlined in section V. This will create a new level of the element reflecting what is currently in production. If the element is associated with a link group, you must also re-link using the procedures outlined in section VII for linking an existing linkcard. You will then move the source and linkcard element(s) to stage 2 via a package.
ENDEVOR AUDATEX PROCEDURES
AUDATEX PROCEDURES
Background: The following are the procedural changes that were created in response to DPROP development. As DPROP developed, and more DB2 was added to programs, it became clear that Audatex could experience some difficulty. Since the batch loads were copied from System C shortly after 4pm, but the batch bind job does not run until 8pm, the 6pm or 9pm Audatex run could run into mismatched links & binds. At the same time we started to look into this problem, it was decided that all Audatex runs for any day should run from the same load. The only reasonable way to solve both of these problems was to move the Audatex jobs from 'PROD.OT.BTCHLOAD' to 'PROD.OT.DI.IMSLOADP'. Since Endevor was installed, the Audatex jobs are now in 'PROD.OT.END.DI.IMSLOAD'. (When the programs are moved to Endevor Stage 2, they are temporarily loaded into PROD.OT.END.STAGE.LOADLIB; then OTBTCHCP copies them to PROD.OT.END.LOADLIB; then OTDILODP copies them to PROD.OT.END.DI.IMSLOAD, from which they execute -- although OTMISCED also executes from PROD.OT.END.LOADLIB via proc OTMISC1P.)
Now Audatex jobs execute from library 'PROD.OT.END.DI.IMSLOAD'. It is updated each morning between 5 and 6 am, which means that all 6 executions of the Audatex procs on a given day run with the same load modules. It also means that anyone making changes to the programs or the procs must proceed with caution.
These programs are included in Audatex processing:
OTMISCED, OT51B10, OT52B10, and OT54B10.
Use the following procedures when making changes to Audatex:
- Move programs to Endevor Stage 2 the DAY BEFORE the changes are to run for the first time.
- Make any proc changes between 6:30 and 10:00 AM the day AFTER PROGRAM CHANGES ARE MADE. (That is, the day the changes are to take effect.) With Endevor, you don't have to physically make the change at a set time:
just set up the production Package Execution Window to run at the appropriate time.
- If changes are made to OTMISCED, review the changes carefully to determine if there are any special considerations. Remember that OTMISCED runs in the batch cycle also, so from the evening it is moved to Endevor Stage 2, the batch cycle will run with the NEW version. This happens because the move action first puts the module into PROD.OT.END.STAGE.LOADLIB; then the external copy job, OTBTCHCP, runs between 7 and 8 PM, copying the contents of the stage load library to PROD.OT.END.LOADLIB. Some fancy footwork may be required to synchronize changes. (Note: this consideration existed prior to the change to PROD.OT.END.DI.IMSLOAD.) However, some of the footwork is
less fancy than before Endevor, because you can set the Package Execution Window to a time that suits your needs.
The program OT55B10 (proc OTAURCVP) runs on system D and continues to run
out of PROD.OT.END.LOADLIB. This means that changes to this program take
effect for the 9 pm Audatex cycle. If this is not acceptable for a
specific change, the program may need to be 'forced' during the day.
Background: The following are the procedural changes that were created in response to DPROP development. As DPROP developed, and more DB2 was added to programs, it became clear that Audatex could experience some difficulty. Since the batch loads were copied from System C shortly after 4pm, but the batch bind job does not run until 8pm, the 6pm or 9pm Audatex run could run into mismatched links & binds. At the same time we started to look into this problem, it was decided that all Audatex runs for any day should run from the same load. The only reasonable way to solve both of these problems was to move the Audatex jobs from 'PROD.OT.BTCHLOAD' to 'PROD.OT.DI.IMSLOADP'. Since Endevor was installed, the Audatex jobs are now in 'PROD.OT.END.DI.IMSLOAD'. (When the programs are moved to Endevor Stage 2, they are temporarily loaded into PROD.OT.END.STAGE.LOADLIB; then OTBTCHCP copies them to PROD.OT.END.LOADLIB; then OTDILODP copies them to PROD.OT.END.DI.IMSLOAD, from which they execute -- although OTMISCED also executes from PROD.OT.END.LOADLIB via proc OTMISC1P.)
Now Audatex jobs execute from library 'PROD.OT.END.DI.IMSLOAD'. It is updated each morning between 5 and 6 am, which means that all 6 executions of the Audatex procs on a given day run with the same load modules. It also means that anyone making changes to the programs or the procs must proceed with caution.
These programs are included in Audatex processing:
OTMISCED, OT51B10, OT52B10, and OT54B10.
Use the following procedures when making changes to Audatex:
- Move programs to Endevor Stage 2 the DAY BEFORE the changes are to run for the first time.
- Make any proc changes between 6:30 and 10:00 AM the day AFTER PROGRAM CHANGES ARE MADE. (That is, the day the changes are to take effect.) With Endevor, you don't have to physically make the change at a set time:
just set up the production Package Execution Window to run at the appropriate time.
- If changes are made to OTMISCED, review the changes carefully to determine if there are any special considerations. Remember that OTMISCED runs in the batch cycle also, so from the evening it is moved to Endevor Stage 2, the batch cycle will run with the NEW version. This happens because the move action first puts the module into PROD.OT.END.STAGE.LOADLIB; then the external copy job, OTBTCHCP, runs between 7 and 8 PM, copying the contents of the stage load library to PROD.OT.END.LOADLIB. Some fancy footwork may be required to synchronize changes. (Note: this consideration existed prior to the change to PROD.OT.END.DI.IMSLOAD.) However, some of the footwork is
less fancy than before Endevor, because you can set the Package Execution Window to a time that suits your needs.
The program OT55B10 (proc OTAURCVP) runs on system D and continues to run
out of PROD.OT.END.LOADLIB. This means that changes to this program take
effect for the 9 pm Audatex cycle. If this is not acceptable for a
specific change, the program may need to be 'forced' during the day.
ENDEVOR DISCHED AND DITABLE PROCEDURES
DISCHED AND DITABLE PROCEDURES
Overview
These two DB2-only transactions are unique in that they are available to the field
for 23 hours a day, 6 days a week (6 X 23). They are retrieved from and moved to
Endevor in the usual way, but they are isolated in their own IMSG region (IMGPRODG).
When Endevor links the transactions, they are moved to PROD.OT.END.STAGE.IMSLOAD.
An external job, OTONLNCP, copies everything from the stage load library to
PROD.OT.END.IMSLOAD, the ACES online load library. However, since the DI members
must occupy their own region, another external job, OTDILODP, copies the DI members
from PROD.OT.END.IMSLOAD to PROD.OT.END.DI.IMSLOAD, from which they actually
execute. This job runs after IMSG is brought down, between 5 and 6 in the morning.
MFS
The normal MFS test-t-prod procedures should be followed. Screen format changes can create problems since the format library flip happens at around midnight, Monday through Friday, and at 5:00 PM on Saturdays. Additionally, the TP room should be notified to stop the transaction (DISCHED or DITABLE) at midnight that weeknight.
DB2 Binds (System G)
Production binds should be done each time a new load module is created regardless of whether SQL has been changed.
When you relink either DI load module and move it back into Stage 2 (production), in addition to moving the load to the correct production load library, Endevor sets up the input to the production bind. It takes the appropriate Endevor DI binddeck member and loads it into the sequential dataset, PROD.OT.DI.PRODBIND. This is input to the bind job, OTD2BDIP. This process ensures that a production bind is done each time either DI load module has changed.
Verification (System G)
1. Check job OTDILODP in $AVRS to make sure the load module was copied to
PROD.OT.END.DI.IMSLOAD.
2. Check job OTD2BDIP to make sure the bind was successful.
Note: Both of these jobs run when IMSG is brought down between 5:00 AM and 6:15 AM the following day.
Overview
These two DB2-only transactions are unique in that they are available to the field
for 23 hours a day, 6 days a week (6 X 23). They are retrieved from and moved to
Endevor in the usual way, but they are isolated in their own IMSG region (IMGPRODG).
When Endevor links the transactions, they are moved to PROD.OT.END.STAGE.IMSLOAD.
An external job, OTONLNCP, copies everything from the stage load library to
PROD.OT.END.IMSLOAD, the ACES online load library. However, since the DI members
must occupy their own region, another external job, OTDILODP, copies the DI members
from PROD.OT.END.IMSLOAD to PROD.OT.END.DI.IMSLOAD, from which they actually
execute. This job runs after IMSG is brought down, between 5 and 6 in the morning.
MFS
The normal MFS test-t-prod procedures should be followed. Screen format changes can create problems since the format library flip happens at around midnight, Monday through Friday, and at 5:00 PM on Saturdays. Additionally, the TP room should be notified to stop the transaction (DISCHED or DITABLE) at midnight that weeknight.
DB2 Binds (System G)
Production binds should be done each time a new load module is created regardless of whether SQL has been changed.
When you relink either DI load module and move it back into Stage 2 (production), in addition to moving the load to the correct production load library, Endevor sets up the input to the production bind. It takes the appropriate Endevor DI binddeck member and loads it into the sequential dataset, PROD.OT.DI.PRODBIND. This is input to the bind job, OTD2BDIP. This process ensures that a production bind is done each time either DI load module has changed.
Verification (System G)
1. Check job OTDILODP in $AVRS to make sure the load module was copied to
PROD.OT.END.DI.IMSLOAD.
2. Check job OTD2BDIP to make sure the bind was successful.
Note: Both of these jobs run when IMSG is brought down between 5:00 AM and 6:15 AM the following day.
ENDEVOR PRODUCTION
PRODUCTION
Forcing a BIND into production during the nightly joblog schedule:
Use this process when making changes to DB2 sub-programs like OTDPDB2P which has numerous BINDS associated with it but the ENDEVOR processor does not automatically stage the proper binds for all plans related to it during the package move.
GENERATE the BINDDECK Element with COPYBACK=Y.
(Option 4 - Generate, from the BATCH OPTIONS MENU).
E - Endevor or 3.PP.E
4 - Claims
3 - Batch
1 - Build SCL
4 - Generate (example follows)
NOTE: Make sure you change COPYBACK (under ACTION OPTIONS) from 'N' to 'Y'. Also be sure to choose the appropriate processor for either a Batch bind or an Online bind.
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMS CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> OTxxxxxx PROCESSOR GROUP ===> BINDxxxx
TYPE ===> BINDDECK
STAGE ===> U U - CLAIMSU C - CLAIMSC
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> N (Y/N)
-------------------------------------------------------------------------------
NOTE: Setting COPYBACK=Y copies the latest version of the BINDDECK to stage U. You must still do a separate package move to put the BINDDECK element back into stage C. This will also move the binddeck to the proper staging library (Online or Batch).
*** Select a PROCESSOR GROUP. *** THIS IS A VERY IMPORTANT STEP ! !
To assign a Processor Group, type a processor name next to PROCESSOR GROUP
(under ACTION OPTIONS above) or type an '*', which will list three processors
for type BINDDECK. When the list is displayed, place an "S" next to the
appropriate processor and hit enter. (DO NOT select the *NOPROC* processor)
BINDBTCH - Stages to the PROD.OT.END.STAGE.BTCHBIND OTD2BBND 8:00pm M-F
BINDONLN - Stages to the PROD.OT.END.STAGE.ONLBIND OTD2BIND 11:00pm M-F, 4pm Sat
Forcing a BIND into production during the nightly joblog schedule:
Use this process when making changes to DB2 sub-programs like OTDPDB2P which has numerous BINDS associated with it but the ENDEVOR processor does not automatically stage the proper binds for all plans related to it during the package move.
GENERATE the BINDDECK Element with COPYBACK=Y.
(Option 4 - Generate, from the BATCH OPTIONS MENU).
E - Endevor or 3.PP.E
4 - Claims
3 - Batch
1 - Build SCL
4 - Generate (example follows)
NOTE: Make sure you change COPYBACK (under ACTION OPTIONS) from 'N' to 'Y'. Also be sure to choose the appropriate processor for either a Batch bind or an Online bind.
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMS CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> OTxxxxxx PROCESSOR GROUP ===> BINDxxxx
TYPE ===> BINDDECK
STAGE ===> U U - CLAIMSU C - CLAIMSC
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> N (Y/N)
-------------------------------------------------------------------------------
NOTE: Setting COPYBACK=Y copies the latest version of the BINDDECK to stage U. You must still do a separate package move to put the BINDDECK element back into stage C. This will also move the binddeck to the proper staging library (Online or Batch).
*** Select a PROCESSOR GROUP. *** THIS IS A VERY IMPORTANT STEP ! !
To assign a Processor Group, type a processor name next to PROCESSOR GROUP
(under ACTION OPTIONS above) or type an '*', which will list three processors
for type BINDDECK. When the list is displayed, place an "S" next to the
appropriate processor and hit enter. (DO NOT select the *NOPROC* processor)
BINDBTCH - Stages to the PROD.OT.END.STAGE.BTCHBIND OTD2BBND 8:00pm M-F
BINDONLN - Stages to the PROD.OT.END.STAGE.ONLBIND OTD2BIND 11:00pm M-F, 4pm Sat
ENDEVOR DB2 PROCEDURES
DB2 PROCEDURES
As part of normal production procedures, Endevor takes care of setting up your binds. When you move a DB2 load module to Endevor stage 2, the bind statements (from PROD.XX.END.BINDDECK where XX denotes the system that the bind cards belong to) for that load module are copied to the correct bind stageing library; PROD.OT.END.STAGE.ONLBIND for online, and PROD.OT.END.STAGE.BTCHBIND for batch. The binds execute on system G. This is true for ACES and SUBRO. FRACS binds need to execute on system A, so its binddecks are copied to PROD.FS.END.STAGE.ONLBIND or PROD.FS.END.STAGE.BTCHBIND.Drive-in App binddecks are copied to PROD.OT.DI.PRODBIND.
DB2 Binds (System G)
There exist four procs that run during the nightly batch cycle that handle
the Binds and Grants and cleanup. They are;
OTD2BIND for On-line & Nonconversational programs. (Executes a Bind & Grant)
OTBINDRP empties out PROD.OT.END.STAGE.ONLBIND
OTD2BBND for Batch programs. (Executes a Bind only).
OTBBNDRP empties out PROD.OT.END.STAGE.BTCHBIND
DB2 Binds (System A)
There exist four procs that run during the nightly batch cycle that handle
the Binds and cleanup. They are;
FSD2BIND for On-line & Nonconversational programs.
FSBINDRP empties out PROD.FS.END.STAGE.ONLBIND
FSD2BBND for Batch programs.
FSBBNDRP empties out PROD.FS.END.STAGE.BTCHBIND
Production binds should be done each time a new load module is created regardless of whether SQL has been changed. Endevor will take care of this for you; you just need to verify that the binddeck(s) have been copied after your move.
Follow the next 5 steps if adding a plan or changing a binddeck:
A. Create bind control cards for plan using generic bind control cards
OTXX94.DB2.BINDCARD(BINDCARD). The new bind control cards should be named the
same as the plan name. Replace XXXXXXXX with the plan name and replace the
YYYYYYYY entries with the correct member names. Be sure that the ACTION
parameter is always REPLACE. REPLACE will always work, even the first time.
The LIBRARY statement may need to have DPROP and XS libraries added. The complete concatenation order is:
LIBRARY (‘SYS1.DPROP.EKYDBRM’ +
‘PROD.OT.END.DBRMLIB’ -
‘PROD.XS.DS.OT.SRVS.DBRMLIB’) -
B. FIRST TIME: Grants: On-line and Nonconversational Programs ONLY:
Edit PROD.OT.PRODGRNT and copy the generic GRANT card from OTXX94.DB2.BINDCARD(GRANT). The Generic GRANT card is as follows:
GRANT EXECUTE ON PLAN XXXXXXXX TO PUBLIC ;
Replace XXXXXXXX with the desired plan name and save dataset. Remember that
other programmers may be doing a GRANT that night so you should copy your
GRANT cards after theirs.
C. Add the BINDDECK to Endevor using a processor group of *NOPROC*. Follow the procedures outlined for adding a linkcard for the first time in section V.3.
D. Update the appropriate binddeck for the system being changed: IE: OTBNDBAT
binds all plans in the ACES Batch system. OTBNDONL binds all ONLINE plans. The
prefixes used are FS, OJ & SU for FRACS, ALF & SUBRO. ALF only uses the
OJBNDBAT member since no online transactions use DB2.
Note: OTBNDBAT and OTBNDONL are only used if all ACES plans need to have BINDs run.
E. Update the DRPROP document found on PALINFO\OVERVIEW\DPROP. Go to page 22
under Nifty Things to Know and update either the table for IMS and DB2
propagation or the table for DB2 only propagation.
NOTE: You need to do this before you move your programs to Endevor stage 2. This is because the move processor will look for the bindcards to copy to the bind stageing library. If it is not there, the processor will get an error and your bind will not be set up.
Verification (System G)
If the bind was done for an On-line program then check job OTD2BIND or FSDBBIND in $AVRS on system G the following day.
If the bind was done for a Batch program then check job OTD2BBND or FSD2BBND in $AVRS on system G the following day.
Emergency Binds
There is JCL in OTXX94.SYSG.DB2.CNTL(BIND) to submit a bind immediately. The procedure is different from the normal bind procedure because Endevor normally does it automatically for you. A good reason for doing this would be a -818 abend (timestamp discrepancies between plan and load module). Please consult your project leader or someone on the technical team if you think this might be necessary. Copy the bindcards from PROD.XX.END.BINDDECK (where XX denotes the system they're associated with) into PROD.OT.BBNDBIND or PROD.OT.PRODBIND. Check that the library statement points to the proper DBRMs. Run the job and check the output in $AVRS.
As part of normal production procedures, Endevor takes care of setting up your binds. When you move a DB2 load module to Endevor stage 2, the bind statements (from PROD.XX.END.BINDDECK where XX denotes the system that the bind cards belong to) for that load module are copied to the correct bind stageing library; PROD.OT.END.STAGE.ONLBIND for online, and PROD.OT.END.STAGE.BTCHBIND for batch. The binds execute on system G. This is true for ACES and SUBRO. FRACS binds need to execute on system A, so its binddecks are copied to PROD.FS.END.STAGE.ONLBIND or PROD.FS.END.STAGE.BTCHBIND.Drive-in App binddecks are copied to PROD.OT.DI.PRODBIND.
DB2 Binds (System G)
There exist four procs that run during the nightly batch cycle that handle
the Binds and Grants and cleanup. They are;
OTD2BIND for On-line & Nonconversational programs. (Executes a Bind & Grant)
OTBINDRP empties out PROD.OT.END.STAGE.ONLBIND
OTD2BBND for Batch programs. (Executes a Bind only).
OTBBNDRP empties out PROD.OT.END.STAGE.BTCHBIND
DB2 Binds (System A)
There exist four procs that run during the nightly batch cycle that handle
the Binds and cleanup. They are;
FSD2BIND for On-line & Nonconversational programs.
FSBINDRP empties out PROD.FS.END.STAGE.ONLBIND
FSD2BBND for Batch programs.
FSBBNDRP empties out PROD.FS.END.STAGE.BTCHBIND
Production binds should be done each time a new load module is created regardless of whether SQL has been changed. Endevor will take care of this for you; you just need to verify that the binddeck(s) have been copied after your move.
Follow the next 5 steps if adding a plan or changing a binddeck:
A. Create bind control cards for plan using generic bind control cards
OTXX94.DB2.BINDCARD(BINDCARD). The new bind control cards should be named the
same as the plan name. Replace XXXXXXXX with the plan name and replace the
YYYYYYYY entries with the correct member names. Be sure that the ACTION
parameter is always REPLACE. REPLACE will always work, even the first time.
The LIBRARY statement may need to have DPROP and XS libraries added. The complete concatenation order is:
LIBRARY (‘SYS1.DPROP.EKYDBRM’ +
‘PROD.OT.END.DBRMLIB’ -
‘PROD.XS.DS.OT.SRVS.DBRMLIB’) -
B. FIRST TIME: Grants: On-line and Nonconversational Programs ONLY:
Edit PROD.OT.PRODGRNT and copy the generic GRANT card from OTXX94.DB2.BINDCARD(GRANT). The Generic GRANT card is as follows:
GRANT EXECUTE ON PLAN XXXXXXXX TO PUBLIC ;
Replace XXXXXXXX with the desired plan name and save dataset. Remember that
other programmers may be doing a GRANT that night so you should copy your
GRANT cards after theirs.
C. Add the BINDDECK to Endevor using a processor group of *NOPROC*. Follow the procedures outlined for adding a linkcard for the first time in section V.3.
D. Update the appropriate binddeck for the system being changed: IE: OTBNDBAT
binds all plans in the ACES Batch system. OTBNDONL binds all ONLINE plans. The
prefixes used are FS, OJ & SU for FRACS, ALF & SUBRO. ALF only uses the
OJBNDBAT member since no online transactions use DB2.
Note: OTBNDBAT and OTBNDONL are only used if all ACES plans need to have BINDs run.
E. Update the DRPROP document found on PALINFO\OVERVIEW\DPROP. Go to page 22
under Nifty Things to Know and update either the table for IMS and DB2
propagation or the table for DB2 only propagation.
NOTE: You need to do this before you move your programs to Endevor stage 2. This is because the move processor will look for the bindcards to copy to the bind stageing library. If it is not there, the processor will get an error and your bind will not be set up.
Verification (System G)
If the bind was done for an On-line program then check job OTD2BIND or FSDBBIND in $AVRS on system G the following day.
If the bind was done for a Batch program then check job OTD2BBND or FSD2BBND in $AVRS on system G the following day.
Emergency Binds
There is JCL in OTXX94.SYSG.DB2.CNTL(BIND) to submit a bind immediately. The procedure is different from the normal bind procedure because Endevor normally does it automatically for you. A good reason for doing this would be a -818 abend (timestamp discrepancies between plan and load module). Please consult your project leader or someone on the technical team if you think this might be necessary. Copy the bindcards from PROD.XX.END.BINDDECK (where XX denotes the system they're associated with) into PROD.OT.BBNDBIND or PROD.OT.PRODBIND. Check that the library statement points to the proper DBRMs. Run the job and check the output in $AVRS.
Adding from Stage C to Stage 2
Adding from Stage C to Stage 2
Using the name of your package (when you moved from Stage U to Stage C):
E - Endevor or 3.PP.E
5 - Claims
4 - Package
9 - Utilities
----------------------------- Package Utilities ------------------------------
Option ===> R
D - Display Package R - Reset Package
E - Export Package # - Delete Package
PACKAGE ID: OTDH94072199A STATUS: EXECUTED
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
TO ISPF LIBRARY:
PROJECT ===> OTDH94 REPLACE MEMBER ===> N (Y/N)
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
ENTER
----------------------------- Package Utilities ---------------- PACKAGE RESET
Option ===>
D - Display Package R - Reset Package
E - Export Package # - Delete Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
TO ISPF LIBRARY:
PROJECT ===> OTDH94 REPLACE MEMBER ===> N (Y/N)
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
PF3
---------------------- Package Foreground Options Menu ------------------------
Option ===> 2
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94072199A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
MODIFY -------------------- CREATE/MODIFY PACKAGE -----------------------------
OPTION ===> E
B - Build Package Actions I - Import SCL
E - Edit Package C - Copy Package
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION ===> OTCOLFSD/F8
PACKAGE TYPE ===> STANDARD
SHARABLE PACKAGE ===> N (Y/N) APPEND TO PACKAGE ===> N (Y/N)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
INPUT PACKAGE ID ===>
FROM ISPF LIBRARY:
PROJECT ===> OTDH94
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
CHANGE ALL STAGE U TO STAGE C, THEN PF3
---------------------- Package Foreground Options Menu ------------------------
Option ===> 3
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94072199A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
CAST -------------------------- CAST PACKAGE ----------------------------------
OPTION ===> C
C - Cast Package S - Display SCL
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
USER ID DATE TIME
CREATED: OTDH94 21JUL99 11:01
LAST UPDATED:
CAST -------------------------- CAST PACKAGE ----------------------------------
OPTION ===> CAST SUCCESSFUL
C - Cast Package S - Display SCL
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
USER ID DATE TIME
CREATED: OTDH94 21JUL99 11:01
LAST UPDATED:
Send a note to two approvers for completion of implementation…
Using the name of your package (when you moved from Stage U to Stage C):
E - Endevor or 3.PP.E
5 - Claims
4 - Package
9 - Utilities
----------------------------- Package Utilities ------------------------------
Option ===> R
D - Display Package R - Reset Package
E - Export Package # - Delete Package
PACKAGE ID: OTDH94072199A STATUS: EXECUTED
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
TO ISPF LIBRARY:
PROJECT ===> OTDH94 REPLACE MEMBER ===> N (Y/N)
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
ENTER
----------------------------- Package Utilities ---------------- PACKAGE RESET
Option ===>
D - Display Package R - Reset Package
E - Export Package # - Delete Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
TO ISPF LIBRARY:
PROJECT ===> OTDH94 REPLACE MEMBER ===> N (Y/N)
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
PF3
---------------------- Package Foreground Options Menu ------------------------
Option ===> 2
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94072199A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
MODIFY -------------------- CREATE/MODIFY PACKAGE -----------------------------
OPTION ===> E
B - Build Package Actions I - Import SCL
E - Edit Package C - Copy Package
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION ===> OTCOLFSD/F8
PACKAGE TYPE ===> STANDARD
SHARABLE PACKAGE ===> N (Y/N) APPEND TO PACKAGE ===> N (Y/N)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
INPUT PACKAGE ID ===>
FROM ISPF LIBRARY:
PROJECT ===> OTDH94
GROUP ===> SCL
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
CHANGE ALL STAGE U TO STAGE C, THEN PF3
---------------------- Package Foreground Options Menu ------------------------
Option ===> 3
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94072199A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
CAST -------------------------- CAST PACKAGE ----------------------------------
OPTION ===> C
C - Cast Package S - Display SCL
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
USER ID DATE TIME
CREATED: OTDH94 21JUL99 11:01
LAST UPDATED:
CAST -------------------------- CAST PACKAGE ----------------------------------
OPTION ===> CAST SUCCESSFUL
C - Cast Package S - Display SCL
N - Add Notes to Package
PACKAGE ID: OTDH94072199A STATUS: IN-EDIT
DESCRIPTION: OTCOLFSD/F8
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> N (Y/N)
EXECUTION WINDOW FROM ===> 21JUL99 00:00 TO ===> 31DEC79 00:00
USER ID DATE TIME
CREATED: OTDH94 21JUL99 11:01
LAST UPDATED:
Send a note to two approvers for completion of implementation…
ENDEVOR MFS UPDATES
MFS UPDATES
The following paragraphs outline the procedures for implementing
MFS members:
- MFS changes should be made only on Friday.
- Retrieve the member from Endevor Stage 2 to yourid.LIB.SOURCE or your own
PDS - this version is basically discarded. A new MFS will be generated
EXCEPT for MFS members: OTR01AMF and OTR31AMF. For OTR01AMF and OTR31AMF
changes, you will edit the MFS directly and not generate a new MFS through
panel Q.10 (TELON 2.1 MFSGEN SECTION MENU).
- Perform the necessary changes to the MFS. This may mean utilizing TDF or
other methods of changing the source code and testing the changes (refer to online testing document on Aces server PAL INFO\CHKLIST\ONLINTST.DOC).
(1) Add the MFS member from your PDS or yourid.LIB.SOURCE to Endevor Stage U, using either FOREGROUND (Option 2 from the Endevor Primary Options Menu) or BATCH (Option 3). BE SURE TO SPECIFY MFSGEN FOR THE PROCESSOR GROUP.
(2) Move it to Endevor Stage C (see sections V.7.a through f).
(along with the associated program change).
(3) Begin Testing.
(4) Add the MFS to production
(5) The move processor will update the DSN 'IMSVSP.MFSBATCH'. This
library is copied to the appropriate systems nightly by an IMS job. The MFS change does not go into effect until the following day. The program
TTPRODS and links will have to be done at the same time so the program
and MFS is not out of sync.
NOTE: IMSVSP.MFSBATCH on system C is copied to a stageing library IMSVSP.FORMAT by IMS job IMHFORMT which runs on system C. This library is accessible to all systems. Then a job on each system runs to copy MFSs from the stageing library (IMSVSP.FORMAT) to the appropriate offline MFS library (IMSVSP.FORMATA or IMSVSP.FORMATB). For example, the job that runs on system G is called IMGFORMT, on system A IMAFORMT, etc. Then the IMSVSP.FORMATA and IMSVSP.FORMATB libraries are swapped so the newest changes are brought online.
Test = generate MFS and format using Q panels (Q.10) *existing way
***Moving MFS with program for purpose of production package.
- When doing 'X' and 'P' MFSGENS there are a few things to look for to double
and triple check your jobs. These days we can't be too careful.
1). Go to 3.PP.D.1 and look at the dataset named 'IMSVSP.MFSBATCH'.
This dataset should be empty unless someone else in the area has
done an MFSGEN that day for 'X' or 'P'.
2). Once the 'SYSC MFS' job has finished, max down to the bottom to
be sure that the correct version of MFS was generated. Located at
the bottom left hand corner of the sysout you should see the
MFS program name. If the MFSGEN was for 'X' the name should be
OXOPPPP (where PPPP is the program name). If the MFSGEN was for
'P' the name should be OTOPPPP.
3). Do a "F 'DEVICE MAPPING' PREV" in the sysout to see a copy of
the screen image. Be sure that the field that you added, changed
or deleted is where it should or shouldn't be.
4). Go back to 3.PP.D.1 and look at the dataset named 'IMSVSP.MFSBATCH'.
This dataset should now have approximately 6 lines related to the
MFSGEN that was submitted.
- First thing the next morning, check the MFS gens in production by issuing
the /FOR (modname) command. Check all systems.
BOCOMP CAPS IMS IMSG IMST
- Be sure to print your package from $AVRS.
- File the production gens in the production cabinet and throw away the old
versions.
- Hold onto the T system gens along with the testing results of the change.
- Delete the job from $AVRS.
- Send a MAIL NOTE to everyone so that they know they don't need to use /TEST
MFS any more.
The following paragraphs outline the procedures for implementing
MFS members:
- MFS changes should be made only on Friday.
- Retrieve the member from Endevor Stage 2 to yourid.LIB.SOURCE or your own
PDS - this version is basically discarded. A new MFS will be generated
EXCEPT for MFS members: OTR01AMF and OTR31AMF. For OTR01AMF and OTR31AMF
changes, you will edit the MFS directly and not generate a new MFS through
panel Q.10 (TELON 2.1 MFSGEN SECTION MENU).
- Perform the necessary changes to the MFS. This may mean utilizing TDF or
other methods of changing the source code and testing the changes (refer to online testing document on Aces server PAL INFO\CHKLIST\ONLINTST.DOC).
(1) Add the MFS member from your PDS or yourid.LIB.SOURCE to Endevor Stage U, using either FOREGROUND (Option 2 from the Endevor Primary Options Menu) or BATCH (Option 3). BE SURE TO SPECIFY MFSGEN FOR THE PROCESSOR GROUP.
(2) Move it to Endevor Stage C (see sections V.7.a through f).
(along with the associated program change).
(3) Begin Testing.
(4) Add the MFS to production
(5) The move processor will update the DSN 'IMSVSP.MFSBATCH'. This
library is copied to the appropriate systems nightly by an IMS job. The MFS change does not go into effect until the following day. The program
TTPRODS and links will have to be done at the same time so the program
and MFS is not out of sync.
NOTE: IMSVSP.MFSBATCH on system C is copied to a stageing library IMSVSP.FORMAT by IMS job IMHFORMT which runs on system C. This library is accessible to all systems. Then a job on each system runs to copy MFSs from the stageing library (IMSVSP.FORMAT) to the appropriate offline MFS library (IMSVSP.FORMATA or IMSVSP.FORMATB). For example, the job that runs on system G is called IMGFORMT, on system A IMAFORMT, etc. Then the IMSVSP.FORMATA and IMSVSP.FORMATB libraries are swapped so the newest changes are brought online.
Test = generate MFS and format using Q panels (Q.10) *existing way
***Moving MFS with program for purpose of production package.
- When doing 'X' and 'P' MFSGENS there are a few things to look for to double
and triple check your jobs. These days we can't be too careful.
1). Go to 3.PP.D.1 and look at the dataset named 'IMSVSP.MFSBATCH'.
This dataset should be empty unless someone else in the area has
done an MFSGEN that day for 'X' or 'P'.
2). Once the 'SYSC MFS' job has finished, max down to the bottom to
be sure that the correct version of MFS was generated. Located at
the bottom left hand corner of the sysout you should see the
MFS program name. If the MFSGEN was for 'X' the name should be
OXOPPPP (where PPPP is the program name). If the MFSGEN was for
'P' the name should be OTOPPPP.
3). Do a "F 'DEVICE MAPPING' PREV" in the sysout to see a copy of
the screen image. Be sure that the field that you added, changed
or deleted is where it should or shouldn't be.
4). Go back to 3.PP.D.1 and look at the dataset named 'IMSVSP.MFSBATCH'.
This dataset should now have approximately 6 lines related to the
MFSGEN that was submitted.
- First thing the next morning, check the MFS gens in production by issuing
the /FOR (modname) command. Check all systems.
BOCOMP CAPS IMS IMSG IMST
- Be sure to print your package from $AVRS.
- File the production gens in the production cabinet and throw away the old
versions.
- Hold onto the T system gens along with the testing results of the change.
- Delete the job from $AVRS.
- Send a MAIL NOTE to everyone so that they know they don't need to use /TEST
MFS any more.
ENDEVOR UTL (JOBSYSIN) UPDATES
UTL (JOBSYSIN) UPDATES
All production members of type UTL (jobsysins, etc) reside in PROD.XX.END.JOBSYSIN (where XX denotes the system the jobsysin is associated with). The following paragraphs outline how to implement UTLs into production.
- Retrieve the UTL from Endevor to yourid.LIB.JOBSYSIN.
- Make the necessary changes.
- Add the UTL from the PDS to Endevor Stage U. You can use FOREGROUND
(Option 2 from the Endevor Primary Options Menu). If adding a new jobsysin,
you must specify processor group *NOPROC*. The former processor group UTL is
not available in the CLAIMST environment.
- Move the UTL from Endevor Stage U to Endevor Stage C, using package
processing (see sections V.7.a through f).
- Begin Testing.
- Add the UTL to production.
- A hard copy printout is not needed. One can browse Endevor to see the most
recent member.
All production members of type UTL (jobsysins, etc) reside in PROD.XX.END.JOBSYSIN (where XX denotes the system the jobsysin is associated with). The following paragraphs outline how to implement UTLs into production.
- Retrieve the UTL from Endevor to yourid.LIB.JOBSYSIN.
- Make the necessary changes.
- Add the UTL from the PDS to Endevor Stage U. You can use FOREGROUND
(Option 2 from the Endevor Primary Options Menu). If adding a new jobsysin,
you must specify processor group *NOPROC*. The former processor group UTL is
not available in the CLAIMST environment.
- Move the UTL from Endevor Stage U to Endevor Stage C, using package
processing (see sections V.7.a through f).
- Begin Testing.
- Add the UTL to production.
- A hard copy printout is not needed. One can browse Endevor to see the most
recent member.
ENDEVOR PROC UPDATES
PROC UPDATES
All production procs reside in SYSTM1.ENDEVOR.PRODPROC on System C - Endevor
Stage 2. The procedures for implementing production procs are as follows.
Sign out the PROC in the signout document located in the current
implementation folder.
Retrieve the proc from Endevor Stage 2 to yourid.LIB.CNTL (or library
of your choice).
- Make the necessary changes.
- Refer to the Disaster Recovery section of the NEWPROC.DOC located in
PAL INFO\CHKLIST on page 3. THIS IS A CRITICAL STEP!!
- Move the proc from the PDS to SYS1.TESTPROC (option 3.3). Be careful not to overlay anyone else's changes. NOTE: Never make changes in SYS1.TESTPROC.
- Add the proc from the SYS1.TESTPROC to Endevor Stage U. You can use
FOREGROUND (Option 2 from the Endevor Primary Options Menu).
- Move the proc from Endevor Stage U to Endevor Stage C, using package
processing (see sections V.7.a through f).
- Test the changed proc. (At the very least do a scan.) Use P=PROC01
on the JOBPARM card to point to SYS1.TESTPROC.
- Add the proc to production.
- Sign the proc back in using the proc signout document
located in the current implementation folder.
All production procs reside in SYSTM1.ENDEVOR.PRODPROC on System C - Endevor
Stage 2. The procedures for implementing production procs are as follows.
Sign out the PROC in the signout document located in the current
implementation folder.
Retrieve the proc from Endevor Stage 2 to yourid.LIB.CNTL (or library
of your choice).
- Make the necessary changes.
- Refer to the Disaster Recovery section of the NEWPROC.DOC located in
PAL INFO\CHKLIST on page 3. THIS IS A CRITICAL STEP!!
- Move the proc from the PDS to SYS1.TESTPROC (option 3.3). Be careful not to overlay anyone else's changes. NOTE: Never make changes in SYS1.TESTPROC.
- Add the proc from the SYS1.TESTPROC to Endevor Stage U. You can use
FOREGROUND (Option 2 from the Endevor Primary Options Menu).
- Move the proc from Endevor Stage U to Endevor Stage C, using package
processing (see sections V.7.a through f).
- Test the changed proc. (At the very least do a scan.) Use P=PROC01
on the JOBPARM card to point to SYS1.TESTPROC.
- Add the proc to production.
- Sign the proc back in using the proc signout document
located in the current implementation folder.
ENDEVOR UPDATES
All production copylib members are located in SYSTM1.ENDEVOR.COPYLIB on System C -
Endevor Stage 2. The following outlines the procedures for implementing
COPYLIB changes.
Sign the COPYLIB member out in signout document located in the current
implementation folder.
- Determine all programs that use the changing COPYLIB member. (An Endevor
scan flags the programs using the copybook; see section XX. Be aware
that these scans will not find references to the "Telon generated" copybook
references such as OTTMUPDA and OTTMWORK.)
- Notify ACES team via MAIL NOTE in a timely manner. You should identify what
source members are involved, what the change involves, Project number (if
applicable), when the change will be implemented, and any other pertinent
information.
- Retrieve the COPYBOOK Element from Stage 2 Endevor to OTXX94.COPYLIB.DATA.
Be careful not to overlay anyone else's changes.
- Make the change (refer to the online testing document on Aces
server PAL INFO\CHKLIST\ONLINTST.DOC).
- ADD the COPYBOOK Element to Endevor Stage U. You can do this using
FOREGROUND (Option 2 from the Endevor Primary Options Menu). Copybooks are
added as *NOPROC* in the mapped environment.
- REGENERATE any affected programs to Endevor Stage U (for information on how to do this, see section VI.1, above) to pick up the new copybook. You may
also need to relink.
- MOVE any affected Elements (programs and copybooks) to Endevor Stage C
(package processing) Bind (Q.14) where necessary.
- Begin Testing.
- Move to production.
- A hard copy of the copy member is not needed. One can see the most
recent version by browsing Endevor Stage 2.
- Send a MAIL NOTE notifying ACES team when the change is complete.
Endevor Stage 2. The following outlines the procedures for implementing
COPYLIB changes.
Sign the COPYLIB member out in signout document located in the current
implementation folder.
- Determine all programs that use the changing COPYLIB member. (An Endevor
scan flags the programs using the copybook; see section XX. Be aware
that these scans will not find references to the "Telon generated" copybook
references such as OTTMUPDA and OTTMWORK.)
- Notify ACES team via MAIL NOTE in a timely manner. You should identify what
source members are involved, what the change involves, Project number (if
applicable), when the change will be implemented, and any other pertinent
information.
- Retrieve the COPYBOOK Element from Stage 2 Endevor to OTXX94.COPYLIB.DATA.
Be careful not to overlay anyone else's changes.
- Make the change (refer to the online testing document on Aces
server PAL INFO\CHKLIST\ONLINTST.DOC).
- ADD the COPYBOOK Element to Endevor Stage U. You can do this using
FOREGROUND (Option 2 from the Endevor Primary Options Menu). Copybooks are
added as *NOPROC* in the mapped environment.
- REGENERATE any affected programs to Endevor Stage U (for information on how to do this, see section VI.1, above) to pick up the new copybook. You may
also need to relink.
- MOVE any affected Elements (programs and copybooks) to Endevor Stage C
(package processing) Bind (Q.14) where necessary.
- Begin Testing.
- Move to production.
- A hard copy of the copy member is not needed. One can see the most
recent version by browsing Endevor Stage 2.
- Send a MAIL NOTE notifying ACES team when the change is complete.
ENDEVOR STATIC LINK PROCESSOR GROUPS
STATIC LINK PROCESSOR GROUPS:
For an electronic version of ACES LINK Process Groups: See 5f
b. Submit the job.
c. When the job has completed, check $AVRS (3.pp.$).
d. Move the LINKCARD Element to Stage C. This is the same as package processing for programs; for more detail, see sections V.7.a through f, above.
e. When the package job has completed, check SDSF to verify that the load module is now in the appropriate stage C library.
For an electronic version of ACES LINK Process Groups: See 5f
b. Submit the job.
c. When the job has completed, check $AVRS (3.pp.$).
d. Move the LINKCARD Element to Stage C. This is the same as package processing for programs; for more detail, see sections V.7.a through f, above.
e. When the package job has completed, check SDSF to verify that the load module is now in the appropriate stage C library.
ENDEVOR LINKCARD
Generating an unchanged LINKCARD
a. GENERATE the LINKCARD Element with COPYBACK=Y. (Option 4 - Generate,
from the BATCH OPTIONS MENU).
E - Endevor or 3.PP.E
4 - Claimst
3 - Batch
1 - Build SCL
4 - Generate (example follows)
NOTE: Make sure you change COPYBACK (under ACTION OPTIONS) from 'N' to
'Y' (see example below).
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> otxxxxxx PROCESSOR GROUP ===>
TYPE ===> LINKCARD
STAGE ===> U U - CLAIMSU C - CLAIMSC
CLAIMSU OR CLAIMSC = “From where you want to run the generate”
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> Y (Y/N)
-------------------------------------------------------------------------------
NOTE: Setting COPYBACK =‘Y’ will locate the source for the generate, which will be from Stage U, C, 1, 2 (in that order). You must still do a separate package move to put the linkcard element back into stage C. Build using map = ‘Y’ for Stage 2 source “From Endevor” means from where do you want to execute the generate processor, NOT from where is the source.
Select a PROCESSOR GROUP.
To assign a Processor Group, type next to PROCESSOR GROUP
(under ACTION OPTIONS):
• one of the processor group names or '*', which the entire list
of Processors for type LINKCARD. When the list is displayed, place
an "S" next to the appropriate processor and hit enter.
a. GENERATE the LINKCARD Element with COPYBACK=Y. (Option 4 - Generate,
from the BATCH OPTIONS MENU).
E - Endevor or 3.PP.E
4 - Claimst
3 - Batch
1 - Build SCL
4 - Generate (example follows)
NOTE: Make sure you change COPYBACK (under ACTION OPTIONS) from 'N' to
'Y' (see example below).
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> otxxxxxx PROCESSOR GROUP ===>
TYPE ===> LINKCARD
STAGE ===> U U - CLAIMSU C - CLAIMSC
CLAIMSU OR CLAIMSC = “From where you want to run the generate”
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> Y (Y/N)
-------------------------------------------------------------------------------
NOTE: Setting COPYBACK =‘Y’ will locate the source for the generate, which will be from Stage U, C, 1, 2 (in that order). You must still do a separate package move to put the linkcard element back into stage C. Build using map = ‘Y’ for Stage 2 source “From Endevor” means from where do you want to execute the generate processor, NOT from where is the source.
Select a PROCESSOR GROUP.
To assign a Processor Group, type next to PROCESSOR GROUP
(under ACTION OPTIONS):
• one of the processor group names or '*', which the entire list
of Processors for type LINKCARD. When the list is displayed, place
an "S" next to the appropriate processor and hit enter.
ENDEVOR LINKS
Linking a program creates a load member in the appropriate Endevor Stage U load library and saves the link edit listing. If the program is standalone, the link occurs during the GENERATE process -- that is, when you ADD it to Stage U or do a GENERATE WITH COPYBACK into Stage U, you are compiling and linking the program; therefore, to put this kind of program into production, nothing more is needed than outlined in the section V, above. But if the program must be linked with other application modules, the link must be done as a separate step, using linkcards. Currently, all online programs use linkcards.
When the element (program or linkcard) is moved to Endevor stage C via a package, the load module is moved from the Stage U load library to the appropriate Stage C libarary - BATCH.OT.END.LOADLIB (for batch programs) or PROD.OT.END.IMSLOADT (for online programs).
1. LINKCARDS.
Endevor has LINKCARDS for every STATIC circle. The linkcards are in PROD.OT.END.LINKCTL or PROD.OJ.LF.END.LINKCTL and contain the INCLUDE statements for every OBJ member in a static circle.
The LINKCARDS and their associated link PROCESSOR GROUPS ARE LOCATED N 5f OF THIS DOCUMENT. (Explanation and/or view listing of the processor groups).
2. LINK AN EXISTING LINKCARD (MOST COMMON SCENARIO).
a. The obj concatenation order is Stage U, Stage C, Stage 1, and Stage 2. Make
sure you are including obj’s from the correct libraries.
b. If you are making CHANGES to the linkcard, retrieve it from Stage C
to yourid.LIB.LINK (or library of your choice)and complete the changes. Add the revised linkcard to Stage U using the instructions for adding a new linkcard (section VII.3,below).
c. If you DID NOT change the linkcard, generate it to Stage U in batch, as follows: (for screen layouts refer to item 4 ahead)
• Select option 3 - BATCH.
• Build the SCL as you do for programs.
• On the SCL generation screen, select Option 4 - GENERATE.
• On the generate screen, select copyback = Y.
• Build using map = Y.
• When done, submit the job using jobname OTXX94# & msgclass H
for (SDSF).
This process is the same as for generating (recompiling) programs; for more detail, see section VI.1.
d. Check the output in SDSF. Max down to the bottom. Verify that the module
was marked as Reentrable/Reusable with AMODE=31 and RMODE=ANY. Load modules
now reside in the appropriate Stage 1 load library. Verify that your OBJs were included and that origin of all other obj’s is correct.
e. Once you have verified that the add job ran successfully, move the link card to Stage C, using Option 4 - PACKAGE (from the Endevor Primary Options menu). This process is the same as for moving programs to Stage C; for greater detail, see sections V.7.a through f, above.
3. ADD A NEW LINKCARD
a. A new LINKCARD must be ADDED to Stage U with the correct processor
group for each system. Below is a sample processor group only! Do not assume this is the processor for your new linkcard.
---------------------------- ADD/UPDATE ELEMENTS ----------------------
OPTION ===> A
blank - Member list A - Add an element U - Update an element
TO ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES GENERATE ELEMENT ===> Y (Y/N)
SUBSYSTEM ===> ACES DELETE INPUT SOURCE ===> N (Y/N)
ELEMENT ===> OTXXXXXX NEW VERSION ===>
TYPE ===> LINKCARD OVERRIDE SIGNOUT ===> N (Y/N)
STAGE: U PROCESSOR GROUP ===> LEB2IL47
UPDATE IF PRESENT ===> N (Y/N)
COMMENT ===>
FROM ISPF LIBRARY: LIST OPTIONS:
PROJECT ===> OTXX94 DISPLAY LIST ===> Y (Y/N)
LIBRARY ===> LIB
TYPE ===> CNTL
MEMBER ===> OTAA2FPP THRU MEMBER ===>
FROM OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
-------------------------------------------------------------------------
b. Submit the newly generated SCL. Check the output in SDSF. Max down to the
bottom. Verify that the module was marked as Reenterable/Reusable with
AMODE=31 and RMODE=ANY. Load modules now reside in the appropriate stage U
load library. Verify that your OBJs were included.
c. Once you have verified that the add job ran successfully, move the link card to Stage C, using Option 4 - PACKAGE (from the Endevor Primary Options menu). This process is the same as for moving programs to Stage C; for greater detail, see sections V.7.a through f, above.
Procedures on how to generate a link without changes follow on the next page.
When the element (program or linkcard) is moved to Endevor stage C via a package, the load module is moved from the Stage U load library to the appropriate Stage C libarary - BATCH.OT.END.LOADLIB (for batch programs) or PROD.OT.END.IMSLOADT (for online programs).
1. LINKCARDS.
Endevor has LINKCARDS for every STATIC circle. The linkcards are in PROD.OT.END.LINKCTL or PROD.OJ.LF.END.LINKCTL and contain the INCLUDE statements for every OBJ member in a static circle.
The LINKCARDS and their associated link PROCESSOR GROUPS ARE LOCATED N 5f OF THIS DOCUMENT. (Explanation and/or view listing of the processor groups).
2. LINK AN EXISTING LINKCARD (MOST COMMON SCENARIO).
a. The obj concatenation order is Stage U, Stage C, Stage 1, and Stage 2. Make
sure you are including obj’s from the correct libraries.
b. If you are making CHANGES to the linkcard, retrieve it from Stage C
to yourid.LIB.LINK (or library of your choice)and complete the changes. Add the revised linkcard to Stage U using the instructions for adding a new linkcard (section VII.3,below).
c. If you DID NOT change the linkcard, generate it to Stage U in batch, as follows: (for screen layouts refer to item 4 ahead)
• Select option 3 - BATCH.
• Build the SCL as you do for programs.
• On the SCL generation screen, select Option 4 - GENERATE.
• On the generate screen, select copyback = Y.
• Build using map = Y.
• When done, submit the job using jobname OTXX94# & msgclass H
for (SDSF).
This process is the same as for generating (recompiling) programs; for more detail, see section VI.1.
d. Check the output in SDSF. Max down to the bottom. Verify that the module
was marked as Reentrable/Reusable with AMODE=31 and RMODE=ANY. Load modules
now reside in the appropriate Stage 1 load library. Verify that your OBJs were included and that origin of all other obj’s is correct.
e. Once you have verified that the add job ran successfully, move the link card to Stage C, using Option 4 - PACKAGE (from the Endevor Primary Options menu). This process is the same as for moving programs to Stage C; for greater detail, see sections V.7.a through f, above.
3. ADD A NEW LINKCARD
a. A new LINKCARD must be ADDED to Stage U with the correct processor
group for each system. Below is a sample processor group only! Do not assume this is the processor for your new linkcard.
---------------------------- ADD/UPDATE ELEMENTS ----------------------
OPTION ===> A
blank - Member list A - Add an element U - Update an element
TO ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES GENERATE ELEMENT ===> Y (Y/N)
SUBSYSTEM ===> ACES DELETE INPUT SOURCE ===> N (Y/N)
ELEMENT ===> OTXXXXXX NEW VERSION ===>
TYPE ===> LINKCARD OVERRIDE SIGNOUT ===> N (Y/N)
STAGE: U PROCESSOR GROUP ===> LEB2IL47
UPDATE IF PRESENT ===> N (Y/N)
COMMENT ===>
FROM ISPF LIBRARY: LIST OPTIONS:
PROJECT ===> OTXX94 DISPLAY LIST ===> Y (Y/N)
LIBRARY ===> LIB
TYPE ===> CNTL
MEMBER ===> OTAA2FPP THRU MEMBER ===>
FROM OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
-------------------------------------------------------------------------
b. Submit the newly generated SCL. Check the output in SDSF. Max down to the
bottom. Verify that the module was marked as Reenterable/Reusable with
AMODE=31 and RMODE=ANY. Load modules now reside in the appropriate stage U
load library. Verify that your OBJs were included.
c. Once you have verified that the add job ran successfully, move the link card to Stage C, using Option 4 - PACKAGE (from the Endevor Primary Options menu). This process is the same as for moving programs to Stage C; for greater detail, see sections V.7.a through f, above.
Procedures on how to generate a link without changes follow on the next page.
ENDEVOR PROGRAME COMPILE
PROGRAM - COMPILE
If you need to recompile a program that you haven't changed (for instance, if you changed a copybook and you want the program to pick up the new version), use Option 4 - GENERATE (from the BATCH OPTIONS MENU). Then move the element from Stage U to Stage C. FOR UPDATES TO MODULES ALL READY LOCATED IN STAGE C, SEE BELOW:
E - Endevor or 3.PP.E
4 - Claimst
3 - Batch
1 - Build SCL
4 - Generate (example follows)
1. GENERATE the element from Stage 2 or Stage C to Stage U; with COPYBACK = Y (Example below). To generate from Stage 2 you must change the “Build using map” indicator to ‘Y’.
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMS CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> otxxxxxxx PROCESSOR GROUP ===>
TYPE ===> COBOL
STAGE ===> 2 1 - CLAIMS1 2 - CLAIMS2
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> Y (Y/N)
NOTE: Setting COPYBACK=Y does two things. It copies the Stage 2 version of the program to stage U then generates (compiles or compiles and links) it. You must still do a separate package move to put the element back into Stage C.
2. Submit the batch job. When the SCL to generate (compile) the program has been
built, PF3 back to the BATCH OPTIONS MENU. Verify that your jobcard is correct
and select option 3 to submit the job.
3. Move the Element to Stage C. This is done via the standard package
processing (see sections V.7.a through f of this document, above).
4. If the program has a linkcard associated with it:
(a) GENERATE the LINKCARD from Stage 2 or Stage C to Stage U, with COPYBACK = Y.
This is the same as the generate process for programs. (“Build using map” =
‘Y’ for Stage 2 source)
(b) MOVE the LINKCARD from Stage U to Stage C. This is also done with
package processing.
(For more information on linkcards, see section VII, below.)
5. Updating an existing module already in Stage C (test).
a. Sign out (retrieve) from Stage C - CLAIMST
b. Add element to Stage U
Generate the link (“Build using map” = ‘Y’ for Stage 2 linkcards)
d. Create a package and move the element(s) from Stage U to Stage C
e. If DB2 is used, bind using the Q panels (Wait until above completed before doing the bind - Q.14)
f. Refresh the Region (if applicable)
If you need to recompile a program that you haven't changed (for instance, if you changed a copybook and you want the program to pick up the new version), use Option 4 - GENERATE (from the BATCH OPTIONS MENU). Then move the element from Stage U to Stage C. FOR UPDATES TO MODULES ALL READY LOCATED IN STAGE C, SEE BELOW:
E - Endevor or 3.PP.E
4 - Claimst
3 - Batch
1 - Build SCL
4 - Generate (example follows)
1. GENERATE the element from Stage 2 or Stage C to Stage U; with COPYBACK = Y (Example below). To generate from Stage 2 you must change the “Build using map” indicator to ‘Y’.
----------------------------- GENERATE ELEMENTS -----------------------------
OPTION ===> g
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
G - Generate element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMS CCID ===>
SYSTEM ===> ACES COPYBACK ===> Y (Y/N)
SUBSYSTEM ===> ACES OVERRIDE SIGNOUT ===> N (Y/N)
ELEMENT ===> otxxxxxxx PROCESSOR GROUP ===>
TYPE ===> COBOL
STAGE ===> 2 1 - CLAIMS1 2 - CLAIMS2
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> Y (Y/N)
NOTE: Setting COPYBACK=Y does two things. It copies the Stage 2 version of the program to stage U then generates (compiles or compiles and links) it. You must still do a separate package move to put the element back into Stage C.
2. Submit the batch job. When the SCL to generate (compile) the program has been
built, PF3 back to the BATCH OPTIONS MENU. Verify that your jobcard is correct
and select option 3 to submit the job.
3. Move the Element to Stage C. This is done via the standard package
processing (see sections V.7.a through f of this document, above).
4. If the program has a linkcard associated with it:
(a) GENERATE the LINKCARD from Stage 2 or Stage C to Stage U, with COPYBACK = Y.
This is the same as the generate process for programs. (“Build using map” =
‘Y’ for Stage 2 source)
(b) MOVE the LINKCARD from Stage U to Stage C. This is also done with
package processing.
(For more information on linkcards, see section VII, below.)
5. Updating an existing module already in Stage C (test).
a. Sign out (retrieve) from Stage C - CLAIMST
b. Add element to Stage U
Generate the link (“Build using map” = ‘Y’ for Stage 2 linkcards)
d. Create a package and move the element(s) from Stage U to Stage C
e. If DB2 is used, bind using the Q panels (Wait until above completed before doing the bind - Q.14)
f. Refresh the Region (if applicable)
ENDEVOR STAGE U TO C PACKAGE
Submit your Stage U to Stage C Package
---------------------- Package Foreground Options Menu ------------------------
Option ===> 5
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94060899A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
for submit pkg screen print……………
10. After the package batch job runs successfully (return code 00 or 04):
a. check STAGE U libraries, verifying that all related members (load modules, DBRMs) were deleted.
b. check the Stage C libraries and verify the changes. The element(s) should
reflect the current date and the DBRM should have the user id used when the
job was submitted. See library document for the library dataset names.
c. Review dataset: IMSVSH.PROCLIB(DFSMPLT7) to see if your program is
preloaded. If it is, you need to refresh the region.
(If someone enters into the screen prior to you completing this step,
they will abend, but the abend will automatically refresh the region).
Refresh the Region:
ISPF Primary Option Menu
Option ===> V.I (to enter Boole & Babbage)
More: +
0 Settings Terminal and user parameters User ID . : OTDH94
1 View Display source data or listings Time. . . : 10:08
2 Edit Create or change source data Terminal. : 3278
3 Utilities Perform utility functions Screen. . : 1
4 Foreground Interactive language processing Language. : ENGLISH
5 Batch Submit job for language processing Appl ID . : ISR
6 Command Enter TSO or Workstation commands TSO logon : QWIKC
7 Dialog Test Perform dialog testing TSO prefix: OTDH94
8 PROD UPDATES Perform production control updates System ID : SYSC
11 Workplace ISPF Object/Action Workplace MVS acct. : TSO00XXX
I INFO Information Management Release . : ISPF 4.4
C CHANGES Display summary of changes
E ENDEVOR ENDEVOR Processing
M VPS 6.1 Local Printing through VPS
O OTC Toolbox OTC Toolbox Main Menu - CASA
P PANVALET Panvalet
Q ACES ACES Tool Box
Enter X to Terminate using log/list defaults
Boole & Babbage ------------ IMS OPERATOR WORKSTATION ------------ AutoOPERATOR
OPTION ===> 6 DATE -- 99/06/10
TIME -- 10:10:04
USERID -- OTDH94
1 STATUS - DISPLAY STATUS OF AN IMS SYSTEM MODE -- ISPF 4.4
2 NETWORK - DISPLAY/MODIFY LINE/TERM/NODE
3 DATABASE - DISPLAY/MODIFY DATABASE
4 TRANSACTION - DISPLAY/MODIFY TRANCODE
5 PROGRAM - DISPLAY/MODIFY PROGRAM
6 REGIONS - DISPLAY/MODIFY IMS REGION
PF1/13: HELP
X EXIT - TERMINATE PF3/15: EXIT
BOOLE AND BABBAGE ------------------ REGIONS ------------------- AutoOPERATOR
COMMAND ===> /sta reg imsotc1t ***enter*** TGT ===> IMSH
#MPPS>> 17/ 1 #QUEUED>> 3 MQC1>> CONNECTED/ 14/ 6 INTVL===> 3
#BMPS>> 2 #QUEUED>> 0 DB2T>> CONNECTED/ 13/ 8 STATUS--- INPUT
#IFPS>> 0 #QUEUED>> 0 DATE----- 99/06/10
#DBTS>> 2/ 0 TIME----- 10:11:22
LC CMDS: P(STOP), A(ABDUMP), C(CANCEL), PW(STOP WFI)
LC JOBNAME TYP TRANCODE PSBNAME LTERM CLS RGN WKSET # SIOS CPU TIME
IMSPM1T MPP 1 500K 25,493 18.93
IMSPM1X MPP 2 1596K 4,747 1.33
IMSWB1X MPP 3 624K 2,996 .93
IMSBM1X MPP 4 276K 2,076 .52
IMSWB1T MPP 5 292K 2,330 .75
IMSMP1T MPP 6 308K 638 .16
IMSOTC1X MPP 8 272K 1,171 .28
IMSPM1Z MPP 9 228K 341 .17
IMSMQ1T MPP 10 500K 4,955 4.89
SYIM86MH BMP CSQQTRMN 11 284K 150 3.74
IMSPRODH MPP 12 260K 1,886 .90
IMSOTC1T MPP 13 2044K 12,372 4.19
TPCICSCT DBT 14 4996K 13,913 24.72
IMSWB2X MPP 16 948K 5,223 1.96
IMSWB2T MPP 17 668K 2,503 .85
IMSMP1X MPP 19 380K 17,655 18.37
YOU WILL SEE THAT ONE IS EXECUTING AND ONE IS WAITING (OR SEVERAL)
- Enter after keying in the /sta command
- Type a P (purge) at the region you want to stop and get refreshed
- Hit enter a few times - you should see IMSOTC1T disappear and then reappear
(when this is done, personnel in the online system clock until it’s completed)
11. Table Edit Programs
- Perform normal steps for modifying a program beginning with Endevor Retrieve
as outlined in section V. Program Updates.
- A specific processor group is assigned to the table edit programs. It will create a load member in PROD.TB.END.STAGE.IMSLOAD.
- PROD.TB.END.STAGE.IMSLOAD is copied to system A, PROD.TB.END.IMSLOAD,
nightly.
---------------------- Package Foreground Options Menu ------------------------
Option ===> 5
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94060899A
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
for submit pkg screen print……………
10. After the package batch job runs successfully (return code 00 or 04):
a. check STAGE U libraries, verifying that all related members (load modules, DBRMs) were deleted.
b. check the Stage C libraries and verify the changes. The element(s) should
reflect the current date and the DBRM should have the user id used when the
job was submitted. See library document for the library dataset names.
c. Review dataset: IMSVSH.PROCLIB(DFSMPLT7) to see if your program is
preloaded. If it is, you need to refresh the region.
(If someone enters into the screen prior to you completing this step,
they will abend, but the abend will automatically refresh the region).
Refresh the Region:
ISPF Primary Option Menu
Option ===> V.I (to enter Boole & Babbage)
More: +
0 Settings Terminal and user parameters User ID . : OTDH94
1 View Display source data or listings Time. . . : 10:08
2 Edit Create or change source data Terminal. : 3278
3 Utilities Perform utility functions Screen. . : 1
4 Foreground Interactive language processing Language. : ENGLISH
5 Batch Submit job for language processing Appl ID . : ISR
6 Command Enter TSO or Workstation commands TSO logon : QWIKC
7 Dialog Test Perform dialog testing TSO prefix: OTDH94
8 PROD UPDATES Perform production control updates System ID : SYSC
11 Workplace ISPF Object/Action Workplace MVS acct. : TSO00XXX
I INFO Information Management Release . : ISPF 4.4
C CHANGES Display summary of changes
E ENDEVOR ENDEVOR Processing
M VPS 6.1 Local Printing through VPS
O OTC Toolbox OTC Toolbox Main Menu - CASA
P PANVALET Panvalet
Q ACES ACES Tool Box
Enter X to Terminate using log/list defaults
Boole & Babbage ------------ IMS OPERATOR WORKSTATION ------------ AutoOPERATOR
OPTION ===> 6 DATE -- 99/06/10
TIME -- 10:10:04
USERID -- OTDH94
1 STATUS - DISPLAY STATUS OF AN IMS SYSTEM MODE -- ISPF 4.4
2 NETWORK - DISPLAY/MODIFY LINE/TERM/NODE
3 DATABASE - DISPLAY/MODIFY DATABASE
4 TRANSACTION - DISPLAY/MODIFY TRANCODE
5 PROGRAM - DISPLAY/MODIFY PROGRAM
6 REGIONS - DISPLAY/MODIFY IMS REGION
PF1/13: HELP
X EXIT - TERMINATE PF3/15: EXIT
BOOLE AND BABBAGE ------------------ REGIONS ------------------- AutoOPERATOR
COMMAND ===> /sta reg imsotc1t ***enter*** TGT ===> IMSH
#MPPS>> 17/ 1 #QUEUED>> 3 MQC1>> CONNECTED/ 14/ 6 INTVL===> 3
#BMPS>> 2 #QUEUED>> 0 DB2T>> CONNECTED/ 13/ 8 STATUS--- INPUT
#IFPS>> 0 #QUEUED>> 0 DATE----- 99/06/10
#DBTS>> 2/ 0 TIME----- 10:11:22
LC CMDS: P(STOP), A(ABDUMP), C(CANCEL), PW(STOP WFI)
LC JOBNAME TYP TRANCODE PSBNAME LTERM CLS RGN WKSET # SIOS CPU TIME
IMSPM1T MPP 1 500K 25,493 18.93
IMSPM1X MPP 2 1596K 4,747 1.33
IMSWB1X MPP 3 624K 2,996 .93
IMSBM1X MPP 4 276K 2,076 .52
IMSWB1T MPP 5 292K 2,330 .75
IMSMP1T MPP 6 308K 638 .16
IMSOTC1X MPP 8 272K 1,171 .28
IMSPM1Z MPP 9 228K 341 .17
IMSMQ1T MPP 10 500K 4,955 4.89
SYIM86MH BMP CSQQTRMN 11 284K 150 3.74
IMSPRODH MPP 12 260K 1,886 .90
IMSOTC1T MPP 13 2044K 12,372 4.19
TPCICSCT DBT 14 4996K 13,913 24.72
IMSWB2X MPP 16 948K 5,223 1.96
IMSWB2T MPP 17 668K 2,503 .85
IMSMP1X MPP 19 380K 17,655 18.37
YOU WILL SEE THAT ONE IS EXECUTING AND ONE IS WAITING (OR SEVERAL)
- Enter after keying in the /sta command
- Type a P (purge) at the region you want to stop and get refreshed
- Hit enter a few times - you should see IMSOTC1T disappear and then reappear
(when this is done, personnel in the online system clock until it’s completed)
11. Table Edit Programs
- Perform normal steps for modifying a program beginning with Endevor Retrieve
as outlined in section V. Program Updates.
- A specific processor group is assigned to the table edit programs. It will create a load member in PROD.TB.END.STAGE.IMSLOAD.
- PROD.TB.END.STAGE.IMSLOAD is copied to system A, PROD.TB.END.IMSLOAD,
nightly.
ENDEVOR CAST
CAST (Example below).
PACKAGE ------------------ PACKAGE OPTIONS MENU -----------------------------
OPTION ===> 3
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
PACKAGE ID ===> OTXX94030294A
LIMIT SELECTION LIST BY PACKAGE STATUS: (Y/N - Options 1 & 9)
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
----------------------------------------------------------------------------
7f. Select C - Cast Package (Example below).
--------------------------------------------------------------------------------
CAST ------------------------- CAST PACKAGE ---------------------------------
OPTION ===> c
C - Cast Package S - Display SCL
PACKAGE ID: OTXX94030294A STATUS: IN-EDIT
DESCRIPTION: MOVE PROGRAM UPDATES TO PRODUCTION
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> Y (Y/N)
EXECUTION WINDOW FROM ===> 02MAR94 00:00 TO ===> 31DEC99 00:00
USER ID DATE TIME
CREATED: OTXX94 02MAR94 13:24
LAST UPDATED:
---------------------------------------------------------------------------
After you have cast the package, the system returns to the PACKAGE OPTIONS MENU, where the message "CAST SUCCESSFUL" is displayed in the upper-right corner.
At this point, you need to review/approve, execute/submit your job (15 Claimst approvers in ACES). This job executes the package and moves the program to production. It is jobname MAENDVR and will be in $AVRS on system C.
8. Approve your Stage U to Stage C package
---------------------- Package Foreground Options Menu ------------------------
Option ===> 4
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94060899A (Your id, today’s date, unique letter)
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
for approve screen print……………
PACKAGE ------------------ PACKAGE OPTIONS MENU -----------------------------
OPTION ===> 3
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
PACKAGE ID ===> OTXX94030294A
LIMIT SELECTION LIST BY PACKAGE STATUS: (Y/N - Options 1 & 9)
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
----------------------------------------------------------------------------
7f. Select C - Cast Package (Example below).
--------------------------------------------------------------------------------
CAST ------------------------- CAST PACKAGE ---------------------------------
OPTION ===> c
C - Cast Package S - Display SCL
PACKAGE ID: OTXX94030294A STATUS: IN-EDIT
DESCRIPTION: MOVE PROGRAM UPDATES TO PRODUCTION
PACKAGE TYPE: STANDARD
SHARABLE PACKAGE: N
VALIDATE COMPONENTS ===> N (Y/N/W)
ENABLE BACKOUT ===> Y (Y/N)
EXECUTION WINDOW FROM ===> 02MAR94 00:00 TO ===> 31DEC99 00:00
USER ID DATE TIME
CREATED: OTXX94 02MAR94 13:24
LAST UPDATED:
---------------------------------------------------------------------------
After you have cast the package, the system returns to the PACKAGE OPTIONS MENU, where the message "CAST SUCCESSFUL" is displayed in the upper-right corner.
At this point, you need to review/approve, execute/submit your job (15 Claimst approvers in ACES). This job executes the package and moves the program to production. It is jobname MAENDVR and will be in $AVRS on system C.
8. Approve your Stage U to Stage C package
---------------------- Package Foreground Options Menu ------------------------
Option ===> 4
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
L DistribuLink - Perform Product Collection Request
Package ID ===> OTDH94060899A (Your id, today’s date, unique letter)
Limit selection list by Package Status. These are used by the DISPLAY
and UTILITIES options:
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
for approve screen print……………
ENDEVOR MOVE OPTION
MOVE (Example below).
------------------------------- SCL GENERATION ------------------------------
OPTION ===> 5
1 DISPLAY - Display an element
2 ADD/UPDATE - Add or update an element into stage 1
3 RETRIEVE - Retrieve or copy an element
4 GENERATE - Execute the Generate Processor for this element
5 MOVE - Move an element to the next inventory location
6 DELETE - Delete an element
7 PRINT ELEMENT - Print elements, changes and detail change history
8 SIGNIN - Explicitly sign-in an element
9 TRANSFER - Transfer elements between two ENDEVOR locations
10 PRINT MEMBER - Print a compressed listing or member
11 LIST ELEMENT - Create List actions for ENDEVOR elements
12 LIST MEMBER - Create List actions for external members
13 ARCHIVE - Archive elements
REQUEST DATA SET: PACKAGE - OTXX94030294A
APPEND: N
-------------------------------------------------------------------------------
7d. Option O - Move Element (Example below).
------------------------------- MOVE ELEMENTS -------------------------------
OPTION ===> o
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
O - Move element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES SYNC ===> N (Y/N)
SUBSYSTEM ===> ACES WITH HISTORY ===> N (Y/N)
ELEMENT ===> othirpt1 RETAIN SIGNOUT ===> N (Y/N)
TYPE ===> COBOL SIGNOUT TO ===>
STAGE ===> U ACKNOWLEDGE ELM JUMP ===> N (Y/N)
U - CLAIMSU C - CLAIMSC DELETE 'FROM' ELEMENT ===>Y (Y/N)
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> N (Y/N)
-------------------------------------------------------------------------------
You may continue to fill in this screen and hit enter for each element to be moved; OR you may leave the element name and type blank, keep DISPLAY LIST=Y and get an element selection list. Put an 'o' next to each element you wish to move in your package. This option builds many SCL statements at once. Make sure “BUILD USING MAP = N” or you will be waiting for a while.
When finished building the package, PF3 to the SCL GENERATION SCREEN. Note that in the upper right hand corner of this screen a message displays "# REQUEST(S) BUILT". This message verifies that the SCL to move the element(s) was built.
PF3 again to the CREATE/MODIFY PACKAGE screen; the upper right hand corner displays
the message "PACKAGE CONSTRUCTED". Then PF3 once more to the PACKAGE OPTIONS MENU.
------------------------------- SCL GENERATION ------------------------------
OPTION ===> 5
1 DISPLAY - Display an element
2 ADD/UPDATE - Add or update an element into stage 1
3 RETRIEVE - Retrieve or copy an element
4 GENERATE - Execute the Generate Processor for this element
5 MOVE - Move an element to the next inventory location
6 DELETE - Delete an element
7 PRINT ELEMENT - Print elements, changes and detail change history
8 SIGNIN - Explicitly sign-in an element
9 TRANSFER - Transfer elements between two ENDEVOR locations
10 PRINT MEMBER - Print a compressed listing or member
11 LIST ELEMENT - Create List actions for ENDEVOR elements
12 LIST MEMBER - Create List actions for external members
13 ARCHIVE - Archive elements
REQUEST DATA SET: PACKAGE - OTXX94030294A
APPEND: N
-------------------------------------------------------------------------------
7d. Option O - Move Element (Example below).
------------------------------- MOVE ELEMENTS -------------------------------
OPTION ===> o
ELEMENT DISPLAY OPTIONS:
blank - Element list S - Summary B - Browse H - History
O - Move element M - Master C - Changes
FROM ENDEVOR: ACTION OPTIONS:
ENVIRONMENT ===> CLAIMST CCID ===>
SYSTEM ===> ACES SYNC ===> N (Y/N)
SUBSYSTEM ===> ACES WITH HISTORY ===> N (Y/N)
ELEMENT ===> othirpt1 RETAIN SIGNOUT ===> N (Y/N)
TYPE ===> COBOL SIGNOUT TO ===>
STAGE ===> U ACKNOWLEDGE ELM JUMP ===> N (Y/N)
U - CLAIMSU C - CLAIMSC DELETE 'FROM' ELEMENT ===>Y (Y/N)
COMMENT ===>
LIST OPTIONS:
DISPLAY LIST ===> Y (Y/N)
WHERE CCID EQ ===>
WHERE PROC GRP EQ ===>
BUILD USING MAP ===> N (Y/N)
-------------------------------------------------------------------------------
You may continue to fill in this screen and hit enter for each element to be moved; OR you may leave the element name and type blank, keep DISPLAY LIST=Y and get an element selection list. Put an 'o' next to each element you wish to move in your package. This option builds many SCL statements at once. Make sure “BUILD USING MAP = N” or you will be waiting for a while.
When finished building the package, PF3 to the SCL GENERATION SCREEN. Note that in the upper right hand corner of this screen a message displays "# REQUEST(S) BUILT". This message verifies that the SCL to move the element(s) was built.
PF3 again to the CREATE/MODIFY PACKAGE screen; the upper right hand corner displays
the message "PACKAGE CONSTRUCTED". Then PF3 once more to the PACKAGE OPTIONS MENU.
CREATING A PACKAGE FROM ENDEVOR PRIMARY OPTIONS MENU
Create a PACKAGE, from the Endevor Primary Options Menu; select:
Option 4 - PACKAGE
Option 2 - CREATE/MODIFY (Example below).
PACKAGE ------------------ PACKAGE OPTIONS MENU -----------------------------
OPTION ===> 2
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
PACKAGE ID ===> otxx94030294a
LIMIT SELECTION LIST BY PACKAGE STATUS: (Y/N - Options 1 & 9)
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
NOTE: The PACKAGE ID should be your 6 position TSO ID, today's date (MMDDYY) and a 1 position sequence letter.
Option B - Build Package Actions (Example below).
-----------------------------------------------------------------------------
MODIFY ------------------- CREATE/MODIFY PACKAGE ----------------------------
OPTION ===> b
B - Build Package Actions I - Import SCL
E - Edit Package C - Copy Package
PACKAGE ID: OTXX94030294A STATUS: IN-EDIT
DESCRIPTION ===> move program updates to Stage C
PACKAGE TYPE ===> STANDARD
SHARABLE PACKAGE ===> N (Y/N) APPEND TO PACKAGE ===> N (Y/N)
ENABLE BACKOUT ===> Y (Y/N)
EXECUTION WINDOW FROM ===> 02MAR94 00:00 TO ===> 31DEC99 00:00
INPUT PACKAGE ID ===>
FROM ISPF LIBRARY:
PROJECT ===> OTXX94
GROUP ===> LIB
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
NOTE: A DESCRIPTION is required.
Option 4 - PACKAGE
Option 2 - CREATE/MODIFY (Example below).
PACKAGE ------------------ PACKAGE OPTIONS MENU -----------------------------
OPTION ===> 2
1 DISPLAY - Display Package Information
2 CREATE/MODIFY - Create or Modify Package
3 CAST - Prepare Package for Review
4 REVIEW - Approve or Deny Package
5 EXECUTE - Submit or Execute Package
6 SHIP - Ship Packages
7 BACKOUT - Perform Backout or Backin Processing
8 COMMIT - Clear Backout Information
9 UTILITIES - Reset, Delete, or Export Package
PACKAGE ID ===> otxx94030294a
LIMIT SELECTION LIST BY PACKAGE STATUS: (Y/N - Options 1 & 9)
In-Edit......... Y In-Execution.... Y
In-Approval..... Y Executed........ Y
Denied.......... Y Committed....... Y
Approved........ Y
NOTE: The PACKAGE ID should be your 6 position TSO ID, today's date (MMDDYY) and a 1 position sequence letter.
Option B - Build Package Actions (Example below).
-----------------------------------------------------------------------------
MODIFY ------------------- CREATE/MODIFY PACKAGE ----------------------------
OPTION ===> b
B - Build Package Actions I - Import SCL
E - Edit Package C - Copy Package
PACKAGE ID: OTXX94030294A STATUS: IN-EDIT
DESCRIPTION ===> move program updates to Stage C
PACKAGE TYPE ===> STANDARD
SHARABLE PACKAGE ===> N (Y/N) APPEND TO PACKAGE ===> N (Y/N)
ENABLE BACKOUT ===> Y (Y/N)
EXECUTION WINDOW FROM ===> 02MAR94 00:00 TO ===> 31DEC99 00:00
INPUT PACKAGE ID ===>
FROM ISPF LIBRARY:
PROJECT ===> OTXX94
GROUP ===> LIB
TYPE ===> CNTL
MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DATA SET NAME ===>
NOTE: A DESCRIPTION is required.
ENDEVOR ACTIONS SUBMITING SCL
Submit SCL (Example below).
BATCH ----------------------- BATCH OPTIONS MENU ----------------------------
OPTION ===> 3
1 BUILD SCL - Build batch SCL actions
2 EDIT - Edit request data set
3 SUBMIT - Submit job for batch processing
4 VALIDATE - Check request data set for syntax errors
5 BUILD JCL - Enter additional JCL to be included with the job
REQUEST DATA SET:
PROJECT ===> OTLD94 APPEND ===> N (Y/N)
GROUP ===> ENDEVOR INCLUDE JCL ===> N (Y/N)
TYPE ===> SCL
MEMBER ===> PGMADD
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DSNAME ===>
JOB STATEMENT INFORMATION:
===> //OTXX94# JOB (44001,FS01,00000,1111),'PROJECT C583', => PROJECT NAME
===> // CLASS=A,MSGCLASS=H,NOTIFY=OT???? => YOUR ID
===> //*
===> //*$AVRS C=OTCACTSD =>(comment what program/linkcard/binddeck/sysin)
NOTE: Make sure the project code in the jobcard is correct. Use Class = A if there are many elements involved.
----------------------------------------------------------------------------------
Select Option 3 to submit the job. This job:
(a) creates a compiled listing;
(b) creates a load module in the appropriate stage U load library or object code in the appropriate stage U object library;
(c) for DB2 programs, creates the DBRM member in the appropriate stage U dbrm library.
• When done, submit the job using jobname OTXX94# & msgclass H (SDSF).
6. Check Stage U libraries for your updated module (can’t move to Stage C if your
not in Stage U). See library document for library dataset names.
7. MOVE - From Stage U to Stage C (Test).
After a successful add, update or generate (for type LINKCARD) to Stage U, a MOVE is done from STAGE U to STAGE C.
You should do all your MOVES in one package (after the ADDS, UPDATES or GENERATES have executed successfully), however, when the package executes, the MOVES will not necessarily be executed in the order that you built the SCL.
The objective of the mapped environment is to use one package for the entire process so this package should contain all elements needed for production. Remember the package name for implementation purposes.
The current ELEMENT TYPE Sequence Processing order for processing packages is available for viewing (listed below) or by going to ENDEVOR panel E;4;1;7 (DISPLAY TYPE). In the ENVIRONMENT ===> field enter 'CLAIMST', leave the SYSTEM ===> field blank, and the TYPE ===> field blank, select the STAGE ===> you wish to view. This will bring up a list of all available systems. Select the desired system by tabbing down to the left of the desired system place a 'S' there and . This will display the current order in which elements will be processed in the package.
ORDER OF OPERATIONS:
--------------------------- TYPE SELECTION LIST ------------ Row 1 to 9 of 9
COMMAND ===> SCROLL ===> CSR
CURRENT ENV: CLAIMST STAGE ID: U SYSTEM: ACES
NEXT ENV: CLAIMST STAGE ID: C SYSTEM: ACES
TYPE TYPE DESCRIPTION
MFS ACES MFS
BINDDECK ACES LINK BIND CONTROL STATEMENTS
LINKCARD ACES LINK CONTROL STATEMENTS
COPYBOOK ACES COPYBOOKS
PROC ACES JCL PROCEDURES
UTL ACES CONTROL CARDS/JOBSYSIN
ASSM ACES ASSEMBLER PROGRAMS
COBOL ACES COBOL PROGRAMS
TELON ACES TELON PROGRAMS
******************************* Bottom of data ********************************
BATCH ----------------------- BATCH OPTIONS MENU ----------------------------
OPTION ===> 3
1 BUILD SCL - Build batch SCL actions
2 EDIT - Edit request data set
3 SUBMIT - Submit job for batch processing
4 VALIDATE - Check request data set for syntax errors
5 BUILD JCL - Enter additional JCL to be included with the job
REQUEST DATA SET:
PROJECT ===> OTLD94 APPEND ===> N (Y/N)
GROUP ===> ENDEVOR INCLUDE JCL ===> N (Y/N)
TYPE ===> SCL
MEMBER ===> PGMADD
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DSNAME ===>
JOB STATEMENT INFORMATION:
===> //OTXX94# JOB (44001,FS01,00000,1111),'PROJECT C583', => PROJECT NAME
===> // CLASS=A,MSGCLASS=H,NOTIFY=OT???? => YOUR ID
===> //*
===> //*$AVRS C=OTCACTSD =>(comment what program/linkcard/binddeck/sysin)
NOTE: Make sure the project code in the jobcard is correct. Use Class = A if there are many elements involved.
----------------------------------------------------------------------------------
Select Option 3 to submit the job. This job:
(a) creates a compiled listing;
(b) creates a load module in the appropriate stage U load library or object code in the appropriate stage U object library;
(c) for DB2 programs, creates the DBRM member in the appropriate stage U dbrm library.
• When done, submit the job using jobname OTXX94# & msgclass H (SDSF).
6. Check Stage U libraries for your updated module (can’t move to Stage C if your
not in Stage U). See library document for library dataset names.
7. MOVE - From Stage U to Stage C (Test).
After a successful add, update or generate (for type LINKCARD) to Stage U, a MOVE is done from STAGE U to STAGE C.
You should do all your MOVES in one package (after the ADDS, UPDATES or GENERATES have executed successfully), however, when the package executes, the MOVES will not necessarily be executed in the order that you built the SCL.
The objective of the mapped environment is to use one package for the entire process so this package should contain all elements needed for production. Remember the package name for implementation purposes.
The current ELEMENT TYPE Sequence Processing order for processing packages is available for viewing (listed below) or by going to ENDEVOR panel E;4;1;7 (DISPLAY TYPE). In the ENVIRONMENT ===> field enter 'CLAIMST', leave the SYSTEM ===> field blank, and the TYPE ===> field blank, select the STAGE ===> you wish to view
ORDER OF OPERATIONS:
--------------------------- TYPE SELECTION LIST ------------ Row 1 to 9 of 9
COMMAND ===> SCROLL ===> CSR
CURRENT ENV: CLAIMST STAGE ID: U SYSTEM: ACES
NEXT ENV: CLAIMST STAGE ID: C SYSTEM: ACES
TYPE TYPE DESCRIPTION
MFS ACES MFS
BINDDECK ACES LINK BIND CONTROL STATEMENTS
LINKCARD ACES LINK CONTROL STATEMENTS
COPYBOOK ACES COPYBOOKS
PROC ACES JCL PROCEDURES
UTL ACES CONTROL CARDS/JOBSYSIN
ASSM ACES ASSEMBLER PROGRAMS
COBOL ACES COBOL PROGRAMS
TELON ACES TELON PROGRAMS
******************************* Bottom of data ********************************
ENDEVOR ACTIONS
Submit SCL (Example below).
BATCH ----------------------- BATCH OPTIONS MENU ----------------------------
OPTION ===> 3
1 BUILD SCL - Build batch SCL actions
2 EDIT - Edit request data set
3 SUBMIT - Submit job for batch processing
4 VALIDATE - Check request data set for syntax errors
5 BUILD JCL - Enter additional JCL to be included with the job
REQUEST DATA SET:
PROJECT ===> OTLD94 APPEND ===> N (Y/N)
GROUP ===> ENDEVOR INCLUDE JCL ===> N (Y/N)
TYPE ===> SCL
MEMBER ===> PGMADD
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DSNAME ===>
JOB STATEMENT INFORMATION:
===> //OTXX94# JOB (44001,FS01,00000,1111),'PROJECT C583', => PROJECT NAME
===> // CLASS=A,MSGCLASS=H,NOTIFY=OT???? => YOUR ID
===> //*
===> //*$AVRS C=OTCACTSD =>(comment what program/linkcard/binddeck/sysin)
NOTE: Make sure the project code in the jobcard is correct. Use Class = A if there are many elements involved.
----------------------------------------------------------------------------------
Select Option 3 to submit the job. This job:
(a) creates a compiled listing;
(b) creates a load module in the appropriate stage U load library or object code in the appropriate stage U object library;
(c) for DB2 programs, creates the DBRM member in the appropriate stage U dbrm library.
• When done, submit the job using jobname OTXX94# & msgclass H (SDSF).
6. Check Stage U libraries for your updated module (can’t move to Stage C if your
not in Stage U). See library document for library dataset names.
7. MOVE - From Stage U to Stage C (Test).
After a successful add, update or generate (for type LINKCARD) to Stage U, a MOVE is done from STAGE U to STAGE C.
You should do all your MOVES in one package (after the ADDS, UPDATES or GENERATES have executed successfully), however, when the package executes, the MOVES will not necessarily be executed in the order that you built the SCL.
The objective of the mapped environment is to use one package for the entire process so this package should contain all elements needed for production. Remember the package name for implementation purposes.
The current ELEMENT TYPE Sequence Processing order for processing packages is available for viewing (listed below) or by going to ENDEVOR panel E;4;1;7 (DISPLAY TYPE). In the ENVIRONMENT ===> field enter 'CLAIMST', leave the SYSTEM ===> field blank, and the TYPE ===> field blank, select the STAGE ===> you wish to view. This will bring up a list of all available systems. Select the desired system by tabbing down to the left of the desired system place a 'S' there and . This will display the current order in which elements will be processed in the package.
ORDER OF OPERATIONS:
--------------------------- TYPE SELECTION LIST ------------ Row 1 to 9 of 9
COMMAND ===> SCROLL ===> CSR
CURRENT ENV: CLAIMST STAGE ID: U SYSTEM: ACES
NEXT ENV: CLAIMST STAGE ID: C SYSTEM: ACES
TYPE TYPE DESCRIPTION
MFS ACES MFS
BINDDECK ACES LINK BIND CONTROL STATEMENTS
LINKCARD ACES LINK CONTROL STATEMENTS
COPYBOOK ACES COPYBOOKS
PROC ACES JCL PROCEDURES
UTL ACES CONTROL CARDS/JOBSYSIN
ASSM ACES ASSEMBLER PROGRAMS
COBOL ACES COBOL PROGRAMS
TELON ACES TELON PROGRAMS
******************************* Bottom of data ********************************
BATCH ----------------------- BATCH OPTIONS MENU ----------------------------
OPTION ===> 3
1 BUILD SCL - Build batch SCL actions
2 EDIT - Edit request data set
3 SUBMIT - Submit job for batch processing
4 VALIDATE - Check request data set for syntax errors
5 BUILD JCL - Enter additional JCL to be included with the job
REQUEST DATA SET:
PROJECT ===> OTLD94 APPEND ===> N (Y/N)
GROUP ===> ENDEVOR INCLUDE JCL ===> N (Y/N)
TYPE ===> SCL
MEMBER ===> PGMADD
OTHER PARTITIONED OR SEQUENTIAL DATA SET:
DSNAME ===>
JOB STATEMENT INFORMATION:
===> //OTXX94# JOB (44001,FS01,00000,1111),'PROJECT C583', => PROJECT NAME
===> // CLASS=A,MSGCLASS=H,NOTIFY=OT???? => YOUR ID
===> //*
===> //*$AVRS C=OTCACTSD =>(comment what program/linkcard/binddeck/sysin)
NOTE: Make sure the project code in the jobcard is correct. Use Class = A if there are many elements involved.
----------------------------------------------------------------------------------
Select Option 3 to submit the job. This job:
(a) creates a compiled listing;
(b) creates a load module in the appropriate stage U load library or object code in the appropriate stage U object library;
(c) for DB2 programs, creates the DBRM member in the appropriate stage U dbrm library.
• When done, submit the job using jobname OTXX94# & msgclass H (SDSF).
6. Check Stage U libraries for your updated module (can’t move to Stage C if your
not in Stage U). See library document for library dataset names.
7. MOVE - From Stage U to Stage C (Test).
After a successful add, update or generate (for type LINKCARD) to Stage U, a MOVE is done from STAGE U to STAGE C.
You should do all your MOVES in one package (after the ADDS, UPDATES or GENERATES have executed successfully), however, when the package executes, the MOVES will not necessarily be executed in the order that you built the SCL.
The objective of the mapped environment is to use one package for the entire process so this package should contain all elements needed for production. Remember the package name for implementation purposes.
The current ELEMENT TYPE Sequence Processing order for processing packages is available for viewing (listed below) or by going to ENDEVOR panel E;4;1;7 (DISPLAY TYPE). In the ENVIRONMENT ===> field enter 'CLAIMST', leave the SYSTEM ===> field blank, and the TYPE ===> field blank, select the STAGE ===> you wish to view
ORDER OF OPERATIONS:
--------------------------- TYPE SELECTION LIST ------------ Row 1 to 9 of 9
COMMAND ===> SCROLL ===> CSR
CURRENT ENV: CLAIMST STAGE ID: U SYSTEM: ACES
NEXT ENV: CLAIMST STAGE ID: C SYSTEM: ACES
TYPE TYPE DESCRIPTION
MFS ACES MFS
BINDDECK ACES LINK BIND CONTROL STATEMENTS
LINKCARD ACES LINK CONTROL STATEMENTS
COPYBOOK ACES COPYBOOKS
PROC ACES JCL PROCEDURES
UTL ACES CONTROL CARDS/JOBSYSIN
ASSM ACES ASSEMBLER PROGRAMS
COBOL ACES COBOL PROGRAMS
TELON ACES TELON PROGRAMS
******************************* Bottom of data ********************************
Subscribe to:
Posts (Atom)
