Understanding and Replacing Deprecated Jam5 Syntax
with Jam7 Syntax

Calling & Defining JPL Functions

• The jpl verb was previously used to call jpl functions. Replace any jpl verbs with the call verb. In Jam5, call was used only for calling C functions. Place a pair of double quotes around string constants being passed in a call statement., if they are not already there. When you change a function call that did not pass parameters before, the call must be changed to use the null parameter ()-these parentheses were optional in Jam5. The null parameter () helps Jam7 know that this is a function call and not a variable assignment if you are assigning the return value to a variable.

  jpl test_procedure TEST call test_procedure ("TEST")

  jpl rtm_status call rtm_status()

  Note that if you have functions in JPL and C with the same name, then all C function names take precedence over JPL proc names. The use of the jpl calling verb would have overridden this precedence, so if the jpl verb is used often, you may want to insure that no duplicate names exist. The current precedence is designed to make it easier to convert jpl procs to C functions without having to recode the screens that call those functions.

  ---

• Another old method used to call functions was with the atch verb. This method was used to call field functions when you are not in that context. (i.e. the function is a field entry function, with the field entry parameters, but you are not calling it from field entry, but just from regular jpl processing.). Replace atch, with call. You also need to provide the field arguments, since these will not automatically be provided.

  atch codeval_entry
call codeval_entry(field_number, field_value, field_occurrence, field_mask)

  If you don't have these values available AND the function you are calling uses them, you will need to determine them. Presumably you'll have some field info, but here's code for doing it without having any field info:

  field_num = @widget("@current")->fldnum
field_value = @widget("@current")
field_occurrence = sm_occur_no()
field_mask = sm_inquire(SC_AFLDMDT)
  . . . .or you could hardcode this - field_mask = MDT | VALIDED

  ---

• Return variables from both JPL and C function calls were not assigned by using the function name as an r-value. Rather, a return variable was predefined using the retvar verb. Then, when the function returned, this variable was automatically filled with the return value.

  To update this syntax, delete retvar statements and change calls to C and JPL functions to use the assignment operator = to save any return codes needed.

  
      vars r
      retvar r
      call test_routine("FIRST")
      if r
           return
  
  
      vars r
      r = test_routine("TEST")
      if r
          return
  
  
      if (test_routine("FIRST"))
          return

  ---

• When defining a function, parameters are now declared without using the parms keyword. The parms keyword is only used now for declaring variables that are passed to the 'unnamed jpl' at the top of a file.
  

  
      proc function
      parms value1, value2
  
  
      proc function (value1, value2)
  

  ---

• For screen and widget entry, exit & validation functions, change any hardcoded constants to use true jam constants. In Jam 5, there were no defined constants for the values of the field and screen status bit-masks. Jam5 programmers would either have used numbers, set global variables with the constant's value, or defined these values in the ldb. All of these solutions should be replaced with constants. Hardcoded constants obviously are hard to read, global variables take up space, and an over-loaded ldb can cause slowdown at every screen entry/exit.

if (flags & 256) if (flags & K_EXPOSE)

INSERT TABLE OF VALUES HERE.

---

Also see the section entitled Excessive Colon Expansion in the Miscellaneous JPL section. This contains additional information about the dereferencing of arguments in function calls.