You are here: Development Standards > Upgrading OSAS > Converting to 7.6x > Programming Changes

# Programming Changes

Several changes may be necessary in order for 7.0 application programs to allow them to run properly under 7.6x.

Merge new GEN Routines

The GENeral routines for GENPC has changed in version 7.6. This was changed to support period locking functionality for OSAS version 7.6. Use the _update utility with your interpreter, along with SDLIB.7.6, to merge in the proper routines.

Expanded O2$

The variable O2$ controls the option settings for each application. Prior to version 7.6, this string was 50 characters long. Starting with version 7.6, this string is now 100 characters long. Make sure programs that must manually retrieve an option string plans for a 100 character string to be returned.

Report Pick Screen Defaults

Most reports now have the ability to save pick screen defaults entered by the user, and be recalled the next time the user (or other users) run this report. This can be quickly done to most report in the following steps:

1. Determine what prompts on the screen you will allow the user to save as a default value. Once this analysis is completed, develop variable names that will be used in a string template.
2. Enter the string template to use in the ‘Program Templates’ function in the Software Developers Kit. This function will create a ‘xx.PTL’ file that can then either be merged into the OSPTL file, or included in your application install. Your file will then be merged into OSPTL when users install your application.
3. Add the 6300 section of code (DRILL) to the pick screen. This code block is a standard block of code that allows users to use the Shift-F3 key to choose a default set of report picks.
4. Add the 6400 section of code that retrieves report picks for the current report, that is set up as the default picks. This section should also set default values into your template in case no default is set up.
5. Convert variable usage on your pick screen so that variables used to save values entered by the user are using the PICK.xxxx, where xxxx is the template name for the variable previously used.
6. Be sure to set high values on thru values as necessary, using “}” for string values, or ‘9’ for numeric values.
7. If you want your F2 windows to allow the user to tag multiple entries, make sure you do the following:
   1. Have your variable name in the xx.PTL file use ‘LIST’ at the end of the variable name (example: VENDFROM, VENDTHRU, VENDLIST).
   2. Set GENINPUT.TAG$ to “Y” on those field that you intend to use an F2 list.
   3. Change your report processing to check key values against PICK.XXXXLIST$, to make sure your data matches only those tagged values.

Period Locking

Version 7.6 adds the ability for users to lock a specific period in any of the applications. Many of these changes were done in our GEN routines to limit the amount of programming changes needed. As an example, GENINPUT.PUB will not let you enter in a period/year combination if that period is locked for a given application. However, some programming changes are needed to complete the period locking feature.

1. If you want your period/year entry field to check if that given period is locked. Change X3 from 12 to 16. Since we have many period/year fields that don’t require lock checking, this new X3 value was added so that periods can be validated for locking.
2. New programs called xxAUDPD.PUB are called from the Accounting Periods function, to check If data exists in files if a user is trying to lock a period. See the General Routines on how the xxAUDPD.PUB programs are developed. You will want to develop these programs for your application to make sure transactions do not exist in files that have a GL period/year in them.
3. Add necessary keys to your files that have GL periods/years in them, so that your xxAUDPD.PUB programs will be optimized for performance. You may have to change your period fields to be character strings instead of numeric fields in this process.
4. In prior versions, you were only allowed to post to a single GL year at a time (either current year or last year). Most post programs have had this ability changes to that you will post to both last year and current year GL files at the same time. Furthermore, if you are not interfaced to General Ledger, you can post to any GL year. Program changes should be done to support this.
5. Post programs should also check to see if transactions exist for a locked period, and based on Resource Manager options, either warn the user or stop the user from posting transactions.

Audit Document Links

A new function for auditing document links was added to Resource Manager. This function looks for and calls xxAUDDOC.PUB, much in the same manner as the Audit GL Accounts function process thru the xxAUDIT.PUB programs. If your application is using document links, you can optionally develop an xxAUDDOC.PUB that will audit your links for validity, and optionally purge those links that are not valid.

Report Archiving

Most report archiving functionality has been developed to not require any program modifications. Standard reports will archive on their own thru changes done in the RM menu programs. If you have an application that prints out various forms, you may want to consider revising your print programs to create specific forms for specific master codes (employees, vendors, customers, etc), then archive those specific forms as needed.

1. Check STBL(“ARCHIVE”) to see if archiving is to be done on the current report. If this is set to ‘1’, then archiving should be done.
2. Generate a text or PDF form as is required for your program, and print it.
3. Save that form as a text file or PDF document to the archive folder. The folder can be retrieved by calling GENDETAR.PUB (see the GEN routines section for more information on this public program).
4. Continue processing on following forms.

Active/Inactive Banks and Jobs

Continuing with the master files, Banks in Resource Manager, and Jobs and Phases in both Job Cost and Contractors’ Job Cost now have an active/inactive flag. Your application should check these flags if they use these master files, to make sure processing is not being done on Banks or Jobs.

Transaction Post Codes

Transaction Post Codes was added so users can see General Ledger entries that were posted from a specific application post. These codes are written to the RMDRxxx at post time, and tie to specific entries in the GLJRxxx file. While optional, this should be done so users can see what GL entries were made by your application posts.

Access to File Maintenance Chains

For version 7.6, major file maintenance chains that have multiple screens to proceed thru have implemented access checking for each screen. This is controlled by a new menu item, that is then checked via GENCODE.PUB for access. Maintenance screens that have a similar structure should use this same functionality for consistency. Screens that a user will not have access to are not allowed to be checked (or answered ‘Yes’ to the screen) on the main maintenance selection screen.