Craig and "U2 Users" list, Thank you for your precise questions (See below the copy of a previous private e-mail).
For the "U2 Users" list, here is the detailed description of GTAR #25455 you quoted to tentatively describe what is the purpose of the internal value for "ASSIGN value TO SYSTEM(1017)" : ----- GTAR............... 25455 Opened............. 07/16/99 Closed............. 08/13/99 Long Description... COPY fails to properly copy records in type 1/19 files. Apparently the fix for gtar 14315 was broken when System(1017) functionality was re-assigned to retrieve a users groups. When 14315 was fixed back in 1995, the fix was to use 'ASSIGN 1 TO SYSTEM(1017)' which according to comments in uv/BP/COPY.B indicated to DBwrite that no conversions should occur to the data being written. (Edit COPY.B program and locate 1017 in code.) For example 'COPY FILA REC1 REC2' would handle 'REC1' properly, but not 'REC2'. It would appear that in the process of handling records in type 1/19 files, the assignment to system(1017) is getting lost. Probably due to it's being used to determine group of user so that chmod/chown/chgrp can be done after record is written to file. See 'workaround' for a modified version of COPY.B program that works. Test case has been provided in /u1/gtar/PGMS/25455cpio.Z. After transferring file to desired location, uncompress file, then extract file using 'cpio -ivcdumB < 25455cpio'. Additional instructions provided in LOGIN paragraph in VOC. Resolution......... Fixed to properly handle T1/19 files. Resolution......... Temporary Solution. The test case provided has a modified version of 'COPY.B' that can be used to work around the problem. To view change to code, edit program and locate *25455 Fixed At........... Due in Release..... 9.5.1D ----- And here are the answers I take from reading the source code and GTAR #25455 : A/ As you noted, so curious that it would appear to programmer's logic : - Per documentation, right assignment : SupplementaryGroupsInDynamicArray = SYSTEM(1017) - Undocumented is the "left" assignment : ASSIGN DoNotConvertFMtoNewLine to SYSTEM(1017) B/ Scope of the "left" assignment for SYSTEM(1017) : The scope of the value assigned to the "SYSTEM(1017)" internal variable is per Basic execution layer. This value is session-wide (This is a "non-stacked" value), BUT it is reset = 0 after each "EXECUTE" layer (why this particular behaviour ? this is an other question ;-)) In details : Question : >Within a program if I ASSIGN 1 TO SYSTEM(1017) does it affect just the next >READ or WRITE, or is it a permanent setting? The "SYSTEM(1017)" internal value can be set only within a program and it remains active until this program perform any "EXECUTE" statement, or, obviously, if this program sets the opposite value by a new "left" assignment. The internal flag is systematically reset after program ending, when returning to TCL. For memory, left assignment of "SYSTEM(1017) is manipulated in the "COPY.B" Basic program, and all its derivated verbs : COPY COPYI COPYP COPY.LIST CP CT Question : >If I ASSIGN x TO SYSTEM(1017) in a called subroutine, will it affect the calling program? A "CALL" to a subroutine doesn't add a Basic Run Machine layer, so the "SYSTEM(1017)" value assigned in the SUBROUTINE would also affect the calling program. Question : >Similarly, if I ASSIGN x TO SYSTEM(1017) in a program and then call a subroutine what will be the effect? If value 1 is assigned to "SYSTEM(1017)" in a calling program, the value is kept until an "EXECUTE" statement is performed anywhere in the program or called subroutines, and it is reset = 0 after the main program ends. Question : >Is there a way to test the current value of this to determine whether character conversion is currently enabled? Practically, not at all. Nothing exists in the product for this (and since the "reverse" syntax have an other purpose, this will certainly never exist). I could suggest you to setup two different programs, each one running step by step (I'm sorry, but I didn't took the time to do this for you) : - The first one is handling the "ASSIGN value to SYSTEM(1017)" statement and performing WRITE and READ upon a Type 1/19 file in the different applicative context you described above. - The second one, according to each step of the first program, will "OPENSEQ" and "READSEQ" the data written by the first program, then, perform the "SEQ" or "SEQS" function in order to check the effects and scope of the "SYSTEM(1017)" internal flag. If you are intented to develop the testing programs I suggest, I'd be happy to get them in return. This would verify how I can read the product source code ;-) ---- I hope this will help you. Regards, Hervé BALESTRIERI Support Technique Avancé - IBM Data Management - Produits "U2" Tel.: (33) 01 49 97 12 20 Fax : (33) 01 49 97 12 21 Web : http://www.ibm.com/software/data/u2/ ----- Forwarded by Herve Balestrieri/France/IBM on 28/01/2004 10:58 ----- "Craig Bennett" <[EMAIL PROTECTED] To: au> cc: Subject: Re: [UV] Scope of ASSIGN 1 TO SYSTEM(1017) 27/01/2004 23:35 Herve, thanks for the direct response. I use ASSIGN 1 TO SYSTEM(1017) in UniVerse to disable LF to @AM conversion when reading from Type 1/Type 19 files. We use this both in our internal software and in packages we distribute across various releases of UV. I have read UniVerse GTAR 25455. Previously I recall it having more information about the use of this feature but the version currently on IBM's website is very limited. The questions I have are: Within a program if I ASSIGN 1 TO SYSTEM(1017) does it affect just the next READ or WRITE, or is it a permanent setting? If I ASSIGN x TO SYSTEM(1017) in a called subroutine, will it affect the calling program? Similarly, if I ASSIGN x TO SYSTEM(1017) in a program and then call a subroutine what will be the effect? Is there a way to test the current value of this to determine whether character conversion is currently enabled? regards, Craig Bennett ----- Original Message ----- From: "Herve Balestrieri" To: <[EMAIL PROTECTED]> Sent: Tuesday, January 27, 2004 7:31 PM Subject: [UV] Scope of ASSIGN 1 TO SYSTEM(1017) Craig, What is "your experience" regarding this specific statement ? Is it UniVerse or UniData ? What I try to understand is what you expect in regard of this particular statement. I'll be happy to answer you in depth after some clarifications, since I have access to the source code of the products. Please reply on individual e-mail address, not the list. Thank you in advance. Regards, Hervé BALESTRIERI Support Technique Avancé - IBM Data Management - Produits "U2" Tel.: (33) 01 49 97 12 20 Fax : (33) 01 49 97 12 21 Web : http://www.ibm.com/software/data/u2/ ----- Forwarded by Herve Balestrieri/France/IBM on 27/01/2004 09:28 ----- To: "U2 Users Discussion List" <[EMAIL PROTECTED]> cc: Sent by: "Craig Bennett" <[EMAIL PROTECTED]> Subject: [UV] Scope of ASSIGN 1 TO SYSTEM(1017) 27/01/2004 00:33 Please respond to U2 Users Discussion List Hi All, can anyone clarify the scope of the statement: ASSIGN n TO SYSTEM(1017) Is it reset by the next READ/WRITE operation? (or does it only apply to the next READ/WRITE operation?). Does it apply only within a subroutine/program? If I have PROGRAM PROG1 .... CALL PROG2 * What will the state of SYSTEM(1017) be here? * Perhaps more importantly, how can I check? END SUBROUTINE PROG2 ASSIGN 1 TO SYSTEM(1017) END Intuition, from experience suggests that the statement does not have side effects outside of the local subroutine, but I wanted to check. thanks, Craig _______________________________________________ u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users _______________________________________________ u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users