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.
Custom Search
