Hello

I´ve found something strange happening in a screen and would like to know if anybody here had already heard of the same problem. I´m running on version 5 and we even tested the problem on earlier versions without finding any difference.

In short, when LScalling an LS-update and exiting normally after the file´s been read, it shows that all the parameters except the keys have been lost by the function process flow.

To illustrate this, let´s say your file contains an A-parameter called PARAM_1 containing the string 'Hello'. Until the exit logic PARAM_1 is equal to this value when asking by a UMSG. After exiting the LS (back in the first LS), PARAM_1 has become blank.

Now the file is correctly read (a UMSG in after read shows it) and is of course not empty. Now I could use a scratch variable to save the parameters I´m interested in reading, but the bug seems so big I couldn´t just let it pass.

So I wonder if anybody here could have the explanation of this?? Is that a known bug.......or am I just crazy?

PS : see details in attachment

Thanks!

Edited by Yann Blondaux, 30 November 2005 - 09:19 AM.

Myself and a colleague thought we were crazy when he experienced the exact same problem. Only way that we could get around it was to use scratch variables, which to say the least gets messy, very messy

Irrespective of "right" or "bugged" it's "ProIV normal"

File vars get passed forwards, but not backwards. Of course, if they "fix" this one day, it's bound to break some code that bank on it working the way it does....

Frankly I don't really follow what's being said here.
Are we talking about an LS-update (ie. ENABLE(&#@LSUPDATE)) or are we talking about a callable update function?
If LS-update, what is meant by "parameter"?

Is this file we're talking about in (A)dd mode?
Are we just talking about the "normal" ProIV behaviour that non-key file variables are cleared for files in (A)dd mode?

Frankly I don't really follow what's being said here.
Are we talking about an LS-update (ie. ENABLE(&#@LSUPDATE)) or are we talking about a callable update function?
If LS-update, what is meant by "parameter"?

Is this file we're talking about in (A)dd mode?
Are we just talking about the "normal" ProIV behaviour that non-key file variables are cleared for files in (A)dd mode?

Hi Richard

Trying to answer your doubts:
- this is about LS-updates (ENABLE(&#@LSUPDATE) if you want), I´m not calling any update function.
- by term 'parameter', I meant the value contained by one field of my file. "The parameter hasn´t been saved" = "The value of the field hasn´t been retained".
- the file is in L mode...

Cheers for the answers
/Yann

Edited by Yann Blondaux, 30 November 2005 - 02:52 PM.

Frankly I don't really follow what's being said here.
Are we talking about an LS-update (ie. ENABLE(&#@LSUPDATE)) or are we talking about a callable update function?
If LS-update, what is meant by "parameter"?

Is this file we're talking about in (A)dd mode?
Are we just talking about the "normal" ProIV behaviour that non-key file variables are cleared for files in (A)dd mode?

Richard,

What he is saying

LS1 Many Time Cycle
LS2 Update Cycle


Somewhere within LS1 he calls LS2 (Or cycle if that makes you happy ), which reads a file in lookup mode to get values etc.

A field variable is then used from the LSUpdate or Update Cycle after the call. This variable ends up being nulls for some reason. I think this is a 5.5/VIP issue, as I don't remember having this problem in 4.6/Studio.

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

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.

The wider issue is with upgrading older Functions, if this really is a change of behaviour (behavior for all US readers!).

I'm investigating potentially moving many thousands of Functions to 5.5, so this could be a real problem.

Yann,

There are a few things I don't really understand about your example attachment (eg. Why use @SYSPASS, Why DO+AR+AV, why no ENABLE(&#@LSUPDATE)..) but anyway, if the read in LS2 is the only use of files then my initial reaction is this is clearly a bug.

Someone should go test this on updates/reports in V5[.5] and on screens/updates/reports on V4.6 ('fraid I don't have time right now - sorry).

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

Yann,

There are a few things I don't really understand about your example attachment (eg. Why use @SYSPASS, Why DO+AR+AV, why no ENABLE(&#@LSUPDATE)..) but anyway, if the read in LS2 is the only use of files then my initial reaction is this is clearly a bug.

Someone should go test this on updates/reports in V5[.5] and on screens/updates/reports on V4.6 ('fraid I don't have time right now - sorry).

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

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 ?

Its all in semantics

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.

Edited by Yann Blondaux, 01 December 2005 - 11:44 AM.

Hi,

Yep, you can use the Update flag set yo Y or L, instead of &#@LSUPDATE.

The field being set to DO+AR+OV is a hangup from old versions of ProIV, I think.

I'm sure you used to have to set these flags... along with the OneTime flag, when LSUPDATEs first came out....

There is one slight difference with using the LSUPDATE flag or &#@LSUPDATE....

If you define your LSUPDATE like this...

ENABLE(&#@LSUPDATE)
KEY = 'AAA'

PagingFlag = 'N'
OneTimeFlag = 'Y'

Then your LSU will read the record with AAA as the key and then exit, just like a OneTime Update.

If you remove the ENABLE(&#@LSUPDATE) and use the LSUPDATE flag set to 'L' then this changes the LSU to read the whole file, and it disregards the OneTime flag...

There is no difference I know of, if the PagingFlag is set to 'Y' though.

Just something to be aware of if you 'mass' convert all your code,

Rob.

Yann, Neil,
Sorry for the &#@LSUPDATE confusion, I haven't really written many serious screen functions since V3

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.

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

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