Conference iosg::all-in-1_v30

Hi,

ALL-IN-1 V3.0 writes an audit log of all changes to user accounts, including
the add/modify/delete that you require.  Assuming that you're using V3.0, you
may find it easier to make use of this file rather than create another one.

See OA$LIB:SM_CHANGE_LOGGER.SCP, OA$DATA_SHARE:SM_CHANGE_LOG.DAT and
SM$CHANGE$LOG form.

If the format of this data file is no use to you, you could add code to the
script (using CM of course) to write your own file.  That way you only need to
update one script to do everything, and don't need to worry about which bits of
ALL-IN-1 do what type of profile update, as they all call this script.

Scott

    Scott got in before me on this one. What he says is correct. I can only
    add that SM change logging is an in-built application that seems to do 
    almost exactly what you want. In fact, I remember when we wrote it, we
    simply searched the code for instances of the WRITE CHANGE/ADD/DELETE
    PROFIL command, and put a logging call around them. Now, we may have
    missed a few instances, but it should do pretty much what your customer
    wants. See the Management Guide, Chapter 15, 15.1-4.
    
    If there are things that it doesn't do, that you want, please tell us,
    because we never got much feedback on this part of the product.
    cheers
    DaveT 

    HI,
    
    Thanks for the prompt response, really appreciate it.
    
    Will 'study'the code carefully.
    
    If I define my field to have 20 characters and when I do a WRITE, would
    the full length be writtenned onto the new sequential file ? full 20
    characters padded with blanks ? If not, how do  I get this functinality
    ? Reason being the program that is going to read the above file has to
    read a certain fixed length as a particular fields, until the last field
    which can be variable.
    
    
    Thanks again,
    Angeline

Angeline,

If you want to write an ordinary sequential text file, you should use the
TEXT_FILE functions.  These will write whatever you give them (ie variable
length data), but you can get round this by manually padding the strings to the
required length if the other application is expecting data in specific positions.

The alternative is to use an ENTRY form and indexed file with WRITE functions,
which will then write fixed-length data (the fields will be in the positions,
and with the lengths, that you specify on the ENTRY form.

Unless the application that uses this file has been very strangely written, it
should be able to read the indexed file sequentially, retrieving the
fixed-length records as required.

So which method you choose depends mainly on the file formats the other
application is expecting (or can understand).

Scott

    Hi,
    
    I have created a sequential file, ssb.dat, by creating a entry form,
    SSBFILE which contains:
    .type
     entry /mode=entry
    .file
     ssb.dat
    
    I managed to insert records into this file by doing a <form ssbfile,
    all went well.
    
    Now, how do I write a script to add records into this file ?
    I tried:
    
    write add ssbfile action = 'add', surname = 'ho'..... 
    write ssbfile action = 'add, surname = 'ho'.....
    
    nothing happens, no error but record not written in ssb.dat. If the
    above works, then I will change the script to pick up fields from the
    current profile record and that should be IT. But, how do I add records
    into a sequential file ? The manuals is of not much help.
    
    As for the TEXT_FILE function, I think this involved much more work, so
    if the above works, I would rather stick with it.
    
    Thanks for all the help so far,
    Angeline

    Hi,
    
    I have some observation that I need some clarification on...
    
    I created a script using the TEXT_FILE function as suggested by .4 and
    inserted it in SM_CHANGE_LOGGER.SCP, under the label success-finish.
    I was hpoing that if the logger is successful, then I will write a
    record into my text file.
    
    However, this does not seem to be the case, for deletion, I got 2
    records on the same user writtened and for addition, sometimes 1
    record, sometimes 2.
    
    my script is very simple:
    text_file open/append ssb #file
    .if oa$status eqs '0' then text_file open/write ssb #file
    
    get #ssbrecord = #sm_actioned ' ' #surname '/' #forename
    text_file write ssb #ssbrecord
    text_file close ssb
    
    I do not think its my script that is causing the problem. Can someone
    explain why sometimes there are 2 records written ? 
    
    when I add a brand new user, no existing VMS account, then I get one
    record writtened in the text file. If its an existing VMS account, then
    I get 2 records writtened, without the #surname and #forename fields.
    
    For deletion, always 2 records, without the #surname and #forename
    fields either.
    
    for Edit, no record gets writtened...???? Does the logger keep tracks
    of editing as well ? I thought so...
    
    Any ideas.....?
    
    
    Thanks again,
    Angeline
                                        

Hi,

>> I have created a sequential file, ssb.dat, by creating a entry form

Just a nit, but a file created this way will be an indexed file.  You can still
read it sequentially, so it shouldn't actually affect anything.

>> write add ssbfile action = 'add', surname = 'ho'.....

It is a source of great annoyance to me that an undocumented "feature" of the
WRITE command is that the '=' between field names and field values must not
have any spaces around it.  Thus your command should look like:

    write add ssbfile action='add',surname='ho'.....

Assuming this fixes your problem, we don't need to worry about your questions
with TEXT_FILE :-)

Scott

Re:    <<< Note 3522.7 by SCOTTC::MARSHALL "Spitfire Drivers Do It Topless" >>>
                       -< How to use the WRITE command >-

> >> write add ssbfile action = 'add', surname = 'ho'.....

>It is a source of great annoyance to me that an undocumented "feature" of the
>WRITE command is that the '=' between field names and field values must not
>have any spaces around it.

Since when?  I just tested out your 'feature' using

	write add phpent user = 'FOOBAR', phone = '123-4567'

and it worked fine.  I've never heard of this problem before.  The only
real 'feature' I remember on doing WRITE ADDs is that for a segmented key
(multiple fields) you need to list each field separately in the Write Add,
ie.  key = FLD1 + FLD2,

	write add formname fld1 = 'xxx', fld2 = 'yyy', other = 'zzz'   etc

Regards,
	Al

    hi,
    
    re;7,  That was how to manual says to create a sequential file. Anyway,
    when I checked the file type, its a sequential file.
    
    will try the new 'feature' and inform u of status.
    
    Anyone for the text_file function ? Is the logger script called twice
    to get 2 entries created or its a 'feature' of the text_file function?
    
    
    thanks,
    angeline

    Hi again,
    
    There is a symbol (?) used in the SM_CHANGE_LOGGER.SCP that check if
    the file exists, - .if oa$dir:#sm_change_log.%whole[#sm_change_log] eqs
    '' then.......
    
    What is OA$DIR ? I checked all the manuals that I have but could not
    find it. Also, would appreciate it if someone could explain what the
    %whole does as well. I tried to change the #sm_change_log to my data
    file and everytime I run the program, a new version gets created....
    
    well, maybe I am just stretching my luck a bit...
    
    I tried the suggestion given in .7, and the result is it did not work.
    I still do not get anything written to my sequential data file....
    from the manual, I noticed that the syntax for WRITE is you have to
    give it a key value. On a sequential file, there is no such thing, is
    that where the problem is......
    
    help......
    
    angeline

    Hi,
    
    I have more observation to note.
    
    The SM_CHANGE_LOGGER.SCP script is called when a ADD operation is
    issued. However, it has 2 parts to it, will write to file when a VMS
    account gets created or a ALL-IN-1 accounts gets created. Same as a
    DELETE option. If you delete the ALL-IN-1 account and the VMS account,
    then 2 records get writtened to file.
    
    The GlobalEdit option also calls this script. However, I am still at a
    loss as to why a normal EDIT does not call this script.... or maybe I
    have not found it. I did a wild search but could not find any .SCP or
    .COM files that invoke this script when editing.
    
    Can someone verify this ? It will be heavenly if a EDIT will also
    invoke this script..... MGT MUA E that is.
    
    Thanks a lot,
    Angeline
    
    p/s I still could not write to my sequential file created by the 
    .type
    entry /mode=entry    ??????

Hi Again,

>> Since when?  I just tested out your 'feature' ... and it worked fine

Hmmm, can't be bothered to check it out but there are definitely situations
in which spaces around the = make it barf.  Maybe it's only certain versions of
ALL-IN-1, who knows.

>> re;7,  That was how to manual says to create a sequential file. Anyway,
>> when I checked the file type, its a sequential file

Hmm... you can ACCESS an existing sequential file using an entry form, but if
you CREATE the file from the entry form then it will be indexed (maybe
nit-picking, but you'll need to be aware of this if you periodically delete and
re-create the log file).  So I presume the file SSB.DAT already existed before
you started trying to access it with the entry form.

>> will try the new 'feature'

Well, if Al is correct, then this isn't the problem.  Please give me a pointer
to your entry form (either .FRM, .FLG, or .FLS and .FLX, I'm not fussy :-)
and I'll see if there's anything wrong with them that would prevent the WRITE
from working.

The first thing that springs to mind is:

>> write add ssbfile action = 'add', surname = 'ho'....

Do you actually have fields ACTION and SURNAME defined on the form?
IE: did you use the FMS layout editor to create the fields, and did you
remember to change the field names from F$0001, etc to those you want?  If you
didn't do this, it would explain why using <FORM lets you add records, but why
WRITE fails.

I'll leave DaveT to answer your questions about SM_CHANGE_LOGGER.SCP...

Scott

Hi Angeline.
Re. .10  The OA$DIR dsab is no longer documented. It is the intention that
    FILE$ be used instead. OA$DIR is still described in Tony Redmond's book 
    ('A Technical Odyssey') on page 252. If you try:
        GET #sm_change_log = 'OA$DATA_SHARE:SM_CHANGE_LOG.DAT'
        GET oa$display = OA$DIR:#sm_change_log.%WHOLE[#sm_change_log]
    you will find the whole expanded file spec returned. %WHOLE returns the
    entire record as a string, rather than individual fields within the 
    record.

Re. .11  
    You are correct that EDITs to the Profile do not call sm_change_logger.
    There wasn't time to do it. It has never raised its head since. You 
    could customise it in very easily, until I (if ever) get round to doing
    it.
Cheers
DaveT

    Hi,
    
    This is how I created my SSBFILE:
    
    ;;.type;;
    entry /mode=entry
    ;;.file;;
    $1$dia2:[allin1]ssb.dat
    ;;action;;
    /post = 'get #action=action'
    ;;surname;;
    /post = 'get #surname=surname'
    
    etc.. and yes, I used the FMS editor to create fhe forma and had also
    change the field names to whatever.
    
    when I do a <create ssbfile, I acutally can see a new ssb.dat file
    created with file organization SEQUENTIAL in the specified directory
    and its locked. only after I exit ALL-IN-1 would I be able to display
    the file contents, which is blank.....
    
    Now, my script to write to the above file goes like this:
    
    get #filename = '$1$dia2:[allin1]ssb.dat'
    .if oa$dir:#filename.%whole[#filename] eqs '' then -
    	.goto create_data_file
    
    .label add_record
    	write add ssbfile action = 'add', -
    		surname = 'ho', -
    		gname   = 'angeline', -
    		company = 'Digital'
    	.if oa$status eqs '1' then .goto finish
    
    .label create_data_file
    	.function create ssbfile
    	.goto add_record
    
    .label finish
    	.exit
    
    
    When I go into CM to execute this script,( <do ssb.scp ) I get a blink
    on my screen but when I check the ssb.dat file, its blank ! Like I
    mentioned previously, if I interactively enter the data by doing a
    <form ssbfile, I will see the data appended to this file.
    
    Any other ideas ? 
    
    Just got confirmation from customer that I need to create a sequential
    file which consists of 10 fix-length fields and 1 variable length
    field. So I just somehow have to use the above method to create this
    file, if only the WRITE command works....., that would save me lots of
    code filling up the blanks on the field length if I chose the TEXT_FILE
    function and then on the variable length field, I will just have to
    concatenate all the different symbols into this to make the field,
    variable = 'g=' gname '!s=' surname '!ou=' dept.........
    
    thanks for looking into the above code to see where I fumble......
    angeline.

    Hi Angeline,
    
    This might seem like a minor point if not trivial but I feel I have to
    make it.
    
    >$1$dia2:[allin1]ssb.dat
    
    I have always refrained from using phyical device names as it is *NOT*
    go practice nor is it very professional.  There have been times where I
    have had to fix problem after ALL-IN-1 IOS was moved to another disk
    and the coding used phyical device names.  This is definately not to be
    encouraged IMHO, we should use logicals instead.
    
    We should be setting a good example and good luck with your
    application.
    
    Regards,
    
    Sunil

    Hi all,
    
    I surrendered !!..... I am finally convinced that I cannot use WRITE to
    add/edit/change/del a sequential file created using en entry form. 
    
    .type                }  this commands WILL actually create a 
     entry /mode=entry   }  SEQUENTIAL file !!!!
    .file                }
     log.txt             }
    
    So I am throwing amm the above out the window and concentrate on using
    the TEXT_FILE function to create my file.
    
    Since my file consists of 10 fixed-length fields, when I assigned a
    value to the field, how do I 'pad' it so that it occupies the
    full-length of the field ? 
    #user = profil.vmsusr[#target], 
    and #user = 'angeline ho' , how do I look for the remaining space in
    the field and then change it to #user = 'angeline ho       '??
    
    Is there a function to do this ?
    
    Thanks again,
    Angeline

    shot in the dark - how about V3.0 function FN$FILL?
    - forces a string to be a specified length by filling
    with a specified character at either front or rear:
    <get #x = FN$FILL(#source_str,#output_len,#fill_char,#front_or_rear)
    - or somethong like that (from memory).
    Or perhaps use the fill characters from FMS itself, since you are now
    using an entry form?
    Cheers
    DaveT

Angeline,

OK, my mistake, yes /MODE=ENTRY does create a sequential file.  Also it appears
that WRITE ADD won't work with sequential files.  I can guess why, but won't
bore you with the details!

I have a couple of suggestions:

1) Don't create a sequential file, create an ordinary indexed file.  Then the
WRITE ADD will work as you want.  The other application should be able to read
the file sequentially: ie if it uses RMS to open the file for sequential
reading, then RMS will "hide" the fact that it's really an indexed file.  It
doesn't have to be a sequential file for your application to read it
sequentially!

3) To pad fields by hand for use in TEXT_FILE (this is just an example to give
you the idea):
    GET #NAME=PROFIL.USER[#KEY]
    GET #VMS=PROFIL.VMSUSR[#KEY]
    GET #ACTION="DELETE"
    GET #OTHER="Some other data"

    GET #DATA=#NAME:30 #VMS:20 #ACTION:10 #OTHER
    TEXT_FILE WRITE filesym #DATA

This will write a record with the ALL-IN-1 username left-justified in a 30
character field, the VMS username left-justified in a 20 character field, the
'action' left-justified in a 10 character field, then the 'other' data in a
variable-length field to the end of the record.

Hope that helps.

Scott

    
    Hi,
    
    I have another question to ask....
    
    In VMS, we can do symbols manipulation like removing certain characters
    from the string eg, "ALL-IN-1" - "-" will give "ALLIN-1"
    
    How can I do that in ALL-IN-1 ?? I have a field which contains initials
    of people. However, I want to remove all the periods (.) from the
    initials in my new file. eg S.H.Ho becomes SHHO
    
    Any idea ? I looked at the FN$ functions but did not find one that
    fit....
    
    
    Many thanks,
    Angeline

    Hi,
    
    A little script should do it:
    
    get #x = fn$upper("S.H.Ho")
    .label again
    get #p = fn$find_token(#x,#i,#j,".")
    .if #p eq 0 then .goto done
    get #x = fn$replace(#x,#i,#i,"")
    .goto again
    .label done
    get oa$display = #x
    .exit
    
    HTH
    
    Stuart

    Hi,
    
    I am having another hiccup with my program here....
    
    When I do a MGT MUA E, I go into SM$PROFILEs, and then I can change
    whatever fields I want...
    
    In the SM$PROFILE, I have:
    ;;surname1;;
    /post='get #surname = surname1'
    
    ;;forename1;;
    /post='get #forename = forename1'
    
    ;;initials1;;
    /post='get #initials = initials1' and so on.. for a number of other
    fields as well. The reason I put this in, is that I need all these
    values to write to another file later in another script.
    
    HOWEVER, if during my editing session, I did not touch the above
    fields, all the temp symbols disappear because there is nothing inside.
    How can I code the entry form so that I will get the temp symbols
    filled up ?? Either with the changed values or the original.
    
    I do not quite understand it but this is how it seem to work now. If I
    changed the value in the field, the temp symbol will contain the new
    value but if I leave the field alone, the symbol does not exist.
    
    Any idea ? .. before I am force to do hard-coded assignment like 
    .if #surname = ' ' then get #surname = profil.surname1[$sm_account]  ??
    
    Also, how do I check the size of a particular message in any of my
    folders ?
    
    
    Thanks a million,
    Angeline
    

    Hi,
    
    Field post-processing only occurs after the user has left the field,
    which means the user must have been there first. However there is also
    form post-processing available, so you can put the code there. In the
    version of SM$PROFILE I'm looking at there is an XOP called
    ~~POST_CHANGE~~ which is invoked by form post-processing, and you could
    add your changes in this XOP.
    
    Cheers
    
    Stuart

    Hi,
    
    I have another question on my programming..
    
    I am trying to also add a screen of input to global edit, just like
    SM$GLOBAL$EDIT but I noticed that the fields from this form is stored
    in a file. My fields are store in temporary symbols......(problem?)
    
    SO I had the following added to SM$GLOBAL$EDIT,
    /post='ifexit\...\form ssbvar'
    and in SSBVAR, I had
    /post='get #c = c\get #n1 = n1\ etc...
    
    However, I noticed (finally) that the temporary symbols do not seem to
    be recognized by the batch file that is calling SM_CHANGE_LOGGER. I had
    modified SM_CHANGE_LOGGER to also write to another text file.
    
    All my added temp symbols were gone when I reached SM_CHANGE_LOGGER,
    however, the temp symbols that contain the values that I added into
    SM$GLOBAL$EDIT, example #depart, #location are still there. I managed
    to retrieve the DEPART, LOCATION fields but not the #C or #n1 fields in
    my text record.
    
    Any idea how I could do that ? I am confused as to why the fields on
    SM$GLOBAL$EDIT can be 'seen' by the SM_CHANGE_LOGGER script when
    invoked by the batch file but not the fields that I added although I
    have created temp symbols for them as well.
    
    After the GE option, I can still retrieve my temp symbols by doing a 
    <get oa$display #c but these symbols just could not be recognized by
    the script. ??? 
    
    Guess I am starring at the scripts and forms for too long a period,
    will take a break but I do hope that someone here can give me a pointer
    as to what I had done wrong.....
    
    The pointers given before this note 3522.1 - 3522.22 were excellent. I
    would have had a much harder time withoug your help. Thank you, all of
    you.
    
    
    A millions thanks,
    Angeline

>>  All my added temp symbols were gone when I reached SM_CHANGE_LOGGER,
>>  however, the temp symbols that contain the values that I added into
>>  SM$GLOBAL$EDIT, example #depart, #location are still there. I managed
>>  to retrieve the DEPART, LOCATION fields but not the #C or #n1 fields in
>>  my text record.
-------
Without seeing your scripts/forms it's getting difficult to follow now
Angeline. But here's a guess that you might want to investigate:
Mua_global_edit.scp performs a dump_cache on the contents of sm$global$edit,
after the data file has been set up. After that, the script 
sm_ge_sa_symbols.scp retrieves the data for the various fields in a FOR 
loop of the data file e.g. GET #ge_depart  = .depart\\-
(this is because it will be working on several accounts). I think perhaps 
your custom fields are getting lost somewhere in this process?

>>  After the GE option, I can still retrieve my temp symbols by doing a 
>>  <get oa$display #c but these symbols just could not be recognized by
>>  the script. ??? 
-----
If they are still there, there should be no reason why they cannot be picked 
up by this (customised) script. Check the simple things (like naming, etc.)

Please try using the debugger to find where in the GE procedure your 
temporary symbols get lost <DEBUG ON    (then GE).
Cheers,
DaveT

    Hi,
    
    ok, I think I am also quite lost in all these scripts.
    
    The question I want to ask is:
    
    if I have a program which starts from a form  and then call some
    scripts and runs in batch mode:
            
             eg. SM$INDEX$OPTIONS 
    			|
    		 SM_SUBMIT_GE -----------------------
    			|                            |
    		 SM$GLOBAL$EDIT                      |
    		 SSBVAR (I added this, it display a  |
     ARG form to get some input from user and        |
     then I saved them in temp symbols during	MUA_GLOBAL_EDIT
     form post processing)   			     |
    						SM_CHANGE_LOGGER
    						SSBTEXT (I added this to
    							 create my text
    							 file)
    
    Would the symbols that I created in SSBVAR be available to be used in
    SSBTEXT ? What I did was saved the fields in temp symbols in SSBVAR and
    then in SSBTEXT, write out the temp symbols into a file. Sound simple ?
    But, unfortunately, when I do a display of the symbols in SSBTEXT, it
    said symbol not found and when I interactively do a <get oa$display
    after the SSBTEXT processing, I can see the correct value..... So this
    leads me to suspect that maybe .. the temp symbols that I saved did not
    get 'passed' to the batch process (MUA_GLOBAL_EDIT.com) which then
    calls the SSBTEXT.
    
    Any idea ?
    
    
    Thanks and have a good weekend,
    Angeline

    Hi Angeline.
    Hope you had a good weekend.
    Thanks for your extended description of the setup. I still have a few
    questions though e.g. I assume SSBTEXT is a form, and if it is, are the
    temporary symbols available immediately before it is called? (Do KP7,
    then Enter Command: get {#your_symbolname} ).
    
    Could you supply us with a pointer to your form lib. where you hold the
    forms SSBVAR & SSBTEXT - we could then copy them across, graft them
    onto a normal global edit and see what's happening?
    Cheers
    DaveT 

    Hi,
    
    SSBTEXT is a script to write out my text file. SSBVAR is a arg form.
    
    I will leave a copy of the above in the following location for you to
    access - MSAVC::SM$GLOBAL$EDIT.ND/SM_SUMBIT_GE.SCP/SM_CHANGE_LOGGER.SCP
    and SSBTEXT.SCP and SSBVAR.ND
    
    I had to copy out the scripts and forms because my development machine
    is not on the network. 
    
    SSBTEXT and SSBVAR are new and if you do a search for ****, you will
    find the changes I added in existing scripts. I have also get a copy of
    the SSBTEXT.DAT file on the net (file generated from SSBTEXT.SCP)
    
    Program flow is (supposed) to be:
    
    SM_SUBMIT_GE.SCP calls SM$GLOBAL$EDIT to compile information to be
    changed, calls SSBVAR to compile additional information on the changed
    records(values are saved in temporary symbols, I did a form post
    processing /post='get #admd = admd....etc')
    
    and then when SM_CHANGE_LOGGER is called, after writing out a record in
    the logger.dat file, it will also invoke my SSBTEXT script to write out
    a record which contains the user information and the additional
    information from the temp. symbols. However, this is not happenning, I
    got my user details in my text file but all my additional information 
    (temp symbols) are gone.
    
    Originally, I had SM$GLOBAL$EDIT invoking FORM SSBVAR but I had also
    tried invoking FORM SSBVAR from SM_SUBMIT_GE.SCP and it still did not
    work.
    
    Hope you can help to check what had gone wrong with my program.
    
    I tried displaying the contents of the temp symbols immediately after
    the form SSBVAR is called but I do not seem to get anything as well.
    Whereas for the other type of transaction (ADD a user, ADD a profile),
    I managed to display the values of the temp symbols. I am really
    puzzled...  The only difference is, on the other transactions, I called
    FORM SSBVAR from another FORM (SM$CREATE and SM$CREATE$PROFILE) and for
    this one, I tried putting in form SM$GLOBAL$EDIT and also in
    SM_SUBMIT_GE.SCP and both did not work. The temp symbols did not seem
    to exist in this case.
    
    Can you please help ?
    
    Thanks again,
    Angeline
    

    Angeline.
    I have copied over files you mention from your default account. 
    Please leave them there for a at least another 24 hrs. in case 
    I need them again.
    I have many things to do, so I probably will not get to patch 
    them onto our system until this evening GMT (10 hours from now).
    I will try to get a reply to you by tomorrow GMT, but if I don't, 
    then I am still busy on it. I will reply one way or the other, 
    eventually.... ;-)
    Cheers
    DaveT

    ...nearly there. The problem lay in the account used to run the
    global edit job.
    cheers,
    DaveT

    HI,
    
    The issue on temp. symbols not been able to pass from script to batch
    file has been resolved. What we did was to include the additional form
    into the original formset, change some original scripts, etc.
    
    I would like to thank Dave Tyldesley for spending time and effort on my
    scripts and helping me to cope with this 'crisis' on programming.
    
    What excellent team work ! 
    
    Once again, from the bottom of my heart, "Thanks a lot, Dave"
    
    Regards,
    Angeline