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
