I have an application with dozens of Maintains and I would like to set the dates so that any year prior to 25 goes to 2000 - 2025, and year after 25 goes to 1926 - 1999. In theory DEFCENT and YRTHRESH should do it when set in the edasprof, but they don't. I don't want to check all the Maintain files out and set them with SYS_MGR.FOCSET. Can anyone tell me a way to make the dates work properly via a global setting? My edasprof.prf currently reads:

MNTCON EXIT_WARNING OFF
-SET NODATA='';
-SET YRTHRESH='25';
-SET DEFCENT='19';

I've tried it about six ways including no quotes, no dash . . . does anyone have an example that works?

J.

This message has been edited. Last edited by: Kerry,

Definitely no dash and no quotes.

SET YRTHRESH = {[-]yy|0}
SET DEFCENT = {cc|19}

SET YRTHRESH = 25
SET DEFCENT = 19

I'm sure these will work if the commands are put in edasprof.prf.

Here's a neat trick to determine the value of a SET commansd (not -SET Dialogue Manager):

-? SET YRTHRESH &ZYRTHRESH
-? SET DEFCENT &ZDEFCENT

-TYPE YRTHRESH &ZYRTHRESH
-TYPE DEFCENT &ZDEFCENT

The first set of lines put the values of the SET commands into DM variables. The second set of lines display the values.

I haven't checked this in Maintain, but I can't see why these values would not be set for the whole WF environment.

Yes, that didn't work for me. I don't know if this is due to Maintain or if I didn't have something exactly correct. Can someone post me an example of tested code?

J.

I have:
SET DEFCENT = 19
SET YRTHRESH = 50

in my EDASPROF and it is working for me.

John - Are the Maintains compiled?

Mark - For a compiled Maintain, which set of century settings would govern their operation -- compile-time or run-time?

They are compiled.

J.

I am being told that the settings should come from compile time.

Mark

Alright, so I need to get the settings in place and then recompile. I'll give that a spin and report back. Thank you for the help.

J.

No change. I blew away the old copies and recompiled, no change. Then I blew the old copies away and set it to not compile, no change as well.

For the record the field is an MDYY.

Simply remarkable how many times I change settings on Reporting Servers and their response back is "No".

S.

Since I had a unit checked out of CM to test this I entered the appropriate SYS_MGR.FOCSET commands to see if that would respond correctly and it did.

J.

John

The setting is from compile time as Mark said.

However, what dates are you trying to convert?

If the date you are converting is MDY to MDYY DFC and YRT will not affect the outcome, convert to A6MDY and then back again.

SET DEFCENT = 17
SET YRTHRESH = 90
-RUN
MAINTAIN FILE EMPDATA

Declare (newDate/yymd;oldDate/a6ymd;);

Case Top

  for all next PIN into empdataStack;

  newDate();

EndCase

Case newDate
  repeat empdataStack.FocCount i/i4=1;
  
    oldDate = empdataStack(i).hiredate;
    newDate = oldDate;

    type empdataStack(i).hiredate;
    type newDate;

  endrepeat i = i + 1;
EndCase

END

DEFINE FILE EMPDATA
OLDDATE/A6YMD = HIREDATE;
NEWDATE/YYMD = OLDDATE;
END
TABLE FILE EMPDATA
PRINT HIREDATE NEWDATE OLDDATE
END

quote:

If the date you are converting is MDY to MDYY DFC and YRT will not affect the outcome,

I'm converting a string of characters to an MDYY field. This is hand-entered values in a field associated with an MDYY, so I don't know if MDY even applies to the situation.

Setting the environment variables in the Maintain code solves the problem:

  
  SYS_MGR.FOCSET("DEFCENT", "19");
  SYS_MGR.FOCSET("YRTHRESH", "22");

I just wish I didn't have to change it in 30+ units in order to correct the problem.

J.

Alright, global redefinition is working, but there's a caveat and I ran into a couple of smokescreens that I had to clear.

-- First off what that I had some Maintain routines that specifically had the DEFCENT value set in them years back (set to 20). So when I added a YRTHRESH of 22 along with the DEFCENT VALUE OF 19 in the profile I got some weird behavior. Dates with a year of 12 became 2112.



That's what tipped me off that the values set in the edasprof had suddenly come alive. YRTHRESH made it through but the DEFCENT value in the MAINTAIN routine was last, so it set the final value.

-- The change had a delay to it. I was getting completely out of Maintain when testing but I'm wondering if the agent was preserving the setting when I came back in. My change to the system was on the 15th and the error began to occur on the 17th. Given how little this new test system is used that may have been how long it took the agent to commit suicide after 99 requests.

The thing I discovered that was very useful is that selecting View Source on the Maintain screen displays the system variable settings right near the top of the sheet:

function FocusEnvironVar() {
this.calendarIconSwitch = 0; 
this.thousandsep = ",";
this.decimalsep = ".";
this.nodata = "";
this.defcent = "19";
this.yrthresh = "22";
}

That allowed me to see very quickly what variables were in force, and showed the mismatch between what was set in the edasprof and what was set in the individual Maintains.

The thing that was super-useful was setting Agent Ransack loose on the application directory on the server and searching for "DEFCENT" in all file types. I very quickly had a list of all Maintain files that had the setting hard-coded in them (5) and the fact that they were compiled on the server and so needed to be recompiled again.

In theory this doesn't need a server restart, but I'm recommending it for Maintain users.

J.