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 progr
