I cannot have the 'P' PRINT function class and the 'E' email function class the same, as this causes problems in our environment. How should the email class be handled? Is there a different class parameter that I should be using for the email function? How should this be addressed when those values need to be different?
We are aware that we have the ability to tab down and change the class manually but would prefer to keep things as simple as possible for the user.
View Release : 14.0
Both the 'P - print attributes' panel and the 'E email attributes' panel use the same mechanisms (NEWCLSL,TSOCLS,JCLASS) to populate the CLASS field.
- The only way that you can have a different class for the E (email) function would be to "HARD CODE" a specific class in your EMAIL attributes panel 'SARP3EM'.
Below is a sample of the SARP3EM email attributes panel showing the one line change that can be made to the panel code that will move an 'E' to the CLASS field for emails:
%&PRD &MOD -----------------%Email Attribute Panel -----------------------------
%Command ===>_OPT +
% ID ---> &ID %
% Job ---> &JNAM % Jobid ---> &JID %
+ Send To %===>_MAILTO +
+ Send CC %===>_MAILCC +
+ Reply To %===>_MAILREP +
+ Mail From %===>_MAILFRO +
+ Subject %===>_MAILSUB +
+ Attachment%===>_MAILFIL +
+ Mail Dest %===>_MAILDES +
+ Page %===>_OPAGE +
+ Record %===>_OREC +
+ Banner %===>_BNR + Class %===>_C+
+Email Message Text:
+ %===>_MAILMS1 +
+ %===>_MAILMS2 +
+ %===>_MAILMS3 +
+ %===>_MAILMS4 +
+ Press%ENTER+to confirm or enter%END+command to cancel
.HELP = SARPTE
C = 'E' <<====== Add this 1 line then oload panel 'SARP3EM'
* IMPORTANT NOTES *
- Make this change to the code in a "user panel library" and then SARDBASE OLOAD it to the database.
- If you make this user modification to the panel code, YOU will be responsible for maintaining that code, should ca/Broadcom replace the 'SARP3EM' panel code through regular maintenance, the addition of new functionality, or a release upgrade.
If after making the above change to the SARP3EM panel, you wanted to LOCK the CLASS field so that users would not be able to override or change the "hard coded" class, you could also change the underscore '_' on the CLASS statement to a pound sign '#' and this will make the class field non-updatable to the users. Example...