Yann Blondaux

I didn't know crickets had a world championship. Highest jumps maybe?
If so yeah the morrocan team has all chance to win

When you do a CDATE on the PRO-IV internal date of 1, you will get the 1st Jan 1800. Each day then increments PRO-IV's internal counter by 1. So today it's been 75399 days since the counter started.

ProIV is really an old language
Now the counters are incremented automatically but in the beginning of the 18' there were a whole range of old women sitting in a drugstore pushing on a huge handle to increment the CDATE counter.

(Sorry, I couldn't help it)

Yann, why not just an alternate def (e.g. CONTRAC2 instead of CONTRACT) with different var names in the same LS - unless you're calling this from all over the function (e.g. for adding to a report file) that would be the more sensible way of doing it.

Cheers

Mike

Hi Mike

I already use an alternate definition when reading the same file inside my LSU. The thing is that I only read one record into my first LS (sel-only) and the whole file with alternate def. in the LSU (sel-partial(' ')), so I have to use 2 LS:s.

Cheers for your answers
/Yann

PS. Thanks for the clarification, I just found it very confusing you would call a file variable a "parameter".

No worries, I should have been more accurate with the terminology.

I might be wrong here, but isn't ENABLE(&#@LSUPDATE) redundant as of 4.6 ? With the introduction of Update LS's or cycles surely this would no longer be needed ?

As long as the LSTP flag is set to L, it wouldn´t be needed.

Yann, is there a reason why you can't read it within the same cycle you calling from ?

In fact yes, the real function (the bigger version of the example I provided) reads the same file in both cycles (calling cycle + LSupdate) but for different references and selection criterion. Anyway the use of scratch variables sorts the problem out.