Jump to content


Photo
- - - - -

DATE4 bug?


7 replies to this topic

#1 Rob Fantini

Rob Fantini

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 267 posts
  • Gender:Male
  • Location:Haverhill, United States

Posted 16 December 1999 - 11:04 AM

using sco , pro4 versions 5.107 abd 4.532.

In any @SF,when in CHANGE MODE , if a DISPLAY-CODE of DATE4 is entered, SPECIAL CHECK changes to DATE. THis happens even when DATE4 was the already in SPECIAL-CHECK.

The above occurs even when the DISPLAY-CODE and SPECIAL CHECK are set to DATE4 in 'Global Dictionary Maintenence' [the @FVARDEF file].

Has anyone else noticed this?

Rob

#2 James Lolley

James Lolley

    Member

  • Members
  • PipPip
  • 13 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 16 December 1999 - 02:31 PM

This is not a problem in Pro-IV version 4.6, revision 1.0.7 with SCO Unix.

#3 Rob Fantini

Rob Fantini

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 267 posts
  • Gender:Male
  • Location:Haverhill, United States

Posted 16 December 1999 - 06:07 PM

I tried here using 1.0.7.

Did you try entering 'DATE4' at 'DISPLAY-CODE'?

Just hitting enter at a DATE4 already there or using ADD mode does not cause the problem to occur.

#4 James Lolley

James Lolley

    Member

  • Members
  • PipPip
  • 13 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 16 December 1999 - 06:30 PM

Ok...if use a scratch variable or an existing file variable that does not have date4 assigned, then yes, if you enter date4 as the display code, the special check defaults to date. But if you change the special check to date4, it stays that way even when you go back in in change mode. Seems to me to be a minor bug since it doesn't affect existing functions.

#5 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 16 December 1999 - 06:56 PM

It's always done that. It's more irritating for me working in 3.09 as DATE is not Y2K compliant and I need to get all our programmers to use GDTVAL which is my Y2K compliant version! If they change a variable name or change it to DATE4 it resets to the DATE SC!

#6 Rob Fantini

Rob Fantini

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 267 posts
  • Gender:Male
  • Location:Haverhill, United States

Posted 16 December 1999 - 07:57 PM

What I ran into was an old a/p pgm which had DATE as the Display Code. Months ago I changed it to DATE4. When I made the change I had neglected to make sure the SC was set back to DATE4.

This week when our a/p dept ran an aging,there were invoices due to be paid in 01/05/1900.

So I made sure to be in at 4:00am to verify that all my programs did not have this defect. Using the file bootstrap definations I changed all occurances of DATE to DATE4 in my @LS's & regenned.
It is a simple bug with a simple fix.

The purpose of a forum like this should not be to show how stupid we are for not knowing simple solutions, but to provide information which may be useful to others.
There is a high probability that other code in the world will be broken thanks to this bug.

#7 Guest_Trev_*

Guest_Trev_*
  • Guests

Posted 17 December 1999 - 03:48 PM

Setting the unix environment variable DATE_SC_50=Y and CDATE_50=Y will ensure that even if DATE s/c is used (or users forget to put in the century) the correct century will be used. These also work on NT, but I do not know about other version.

#8 Rob Fantini

Rob Fantini

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 267 posts
  • Gender:Male
  • Location:Haverhill, United States

Posted 20 December 1999 - 03:02 AM

Thanks for the reminder on DATE_SC_50.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users