Conference iosg::all-in-1_v30

    This issue is critical now, so if someone is planning on responding,
    please do it now.  Thanks, and I owe you one...
    
    David
    

I'll stick my neck out and say that, from my knowldege of the way NETWORK is
used, extending the field size won't break anything.

But I don't have time to check this thoroughly, so can't guarantee it.

Sorry, that's the best I can do for now.

Scott

	I'd have to go along with Scott.  The particular field is not a key
field, so the index structure will not change.  And ALL-IN-1 *always* (being a
well-constructed application!) accesses its information via the field name
table, not by extracting specific bytes from the record.  8^)

	So as long as the field name doesn't change, I believe you will be OK.

	F

    
    What about the Network Profile Update process? Won't changing the
    record layout of NETWORK.DAT affect this process?
    
    The Network Profile Update option runs an image named SMNETUPDT.EXE
    which probably expects the data in a standard format, eg look for the
    DELETED flat at column 375.  
    
    It seems to me that if you extend the NETWORK ADDRESS field in
    NETWORK.DAT you will overwrite some other fields.  If the NETWORK
    ADDRESS field is extended to 100 bytes it would overwrite the
    LAST_UPDATE, MULTINODE, and DELETED fields, wouldn't it?
    
    Don't get me wrong, I hope this will work because it would simplify a
    lot of people's lives when trying to integrate X.400 addresses into
    NETWORK.DAT.
    
    
    -Rick

Hi,

SMNETUPDT will still work if you change the size of the NETWORK field.  It won't
work if you change the size of the user, node, timestamp, mnode or del_flag
fields (those might not be the correct field names, but it's obvious which
fields I mean!), or if you change the order of any of those fields.

Scott

    Now, to add some additional complexity....
    
    If the address field of NETWORK.DAT is increased in size on one
    ALL-IN-1 system, does this have to be replicated on all other ALL-IN-1
    systems on the network?  I ask this because Kellogg uses ALL-IN-1
    housekeeping procedures to synchronize their 7 ALL-IN-1 VAXclusters on
    a daily basis.
    
    David
    

Hi,

Yes, all the NETWORK files on your network must have the same format / record
size.  Or to be more specific, all those that are accessed by SMNETUPDT to copy
records from one node to another.  SMNETUPDT copies records "whole" and doesn't
worry about field sizes or contents, so these must be the same on both "sending"
and "receiving" nodes.

Apart from SMNETUPDT, you probably wouldn't have any problems with
different size NETWORK fields / records on different nodes.  So if it's going
to take a while to convert all the files, just stop using the UA housekeeping
job (the one that runs SMNETUPDT) during that period.

Scott

    Just a quick note to let everyone know that modifying NETWORK.DAT to
    increase the network address field size works.  The customer is running
    it in production with no problems.  I have a detailed script that runs
    through the entire process.  When completed, I'll post it for use by
    others.
    
    David
    

    Modifying NETWORK.DAT and the appropriate ALL-IN-1 forms works just
    great, except that SMNETUPDT.EXE no longer works.  This program has the
    NETWORK.DAT record layout hardcoded, so when it checks the timestamp
    field, it's now looking at some characters in the NETWORK address
    field.  In order to make this work, SMNETUPDT.BAS has to be modified. 
    
    Does anyone know who owns the source code?  I will either have to
    modify the program or rewrite a functional equivalent to make UA work. 
    I'd rather modify SMNETUPDT.BAS.  It will be easier and faster to work
    with a program that already works.
    
    Thanks in advance and for your continued support...
    
    David
    

Quick reply...

I checked the SMNETUPDT when you originally asked the question.  It should work
with different field lengths, as long as you don't change the field order.

IOSG (the group that makes ALL-IN-1) "own" the source, and it's unlikely that
we could just give it out to anyone to modify.

I'll try and give you a more in-depth reply later when I've had a chance to
look at the SMNETUPDT source again.

Scott

First, the NETWORK form (and hence the NETWORK.DAT file) has the following
record structure in V2.3, V2.4 and V3.0.

     Form   NETWORK                          | Len | Row | Col | Posn | Set 
    Field:  USER                             |  30 |   3 |  14 |    0 |  0    
    Field:  NODE                             |   6 |   3 |  58 |   30 |  0    
    Field:  TIMESTAMP                        |  16 |  20 |  15 |   36 |  0    
    Field:  FULNAM                           |  32 |   4 |  14 |   52 |  0    
    Field:  TITLE                            |  30 |   5 |  14 |   84 |  0    
    Field:  DEPART                           |  24 |   6 |  14 |  114 |  0    
    Field:  PHONE                            |  20 |   8 |  14 |  138 |  0    
    Field:  ADDR1                            |  30 |  10 |  14 |  158 |  0    
    Field:  ADDR2                            |  30 |  11 |  14 |  188 |  0    
    Field:  ADDR3                            |  30 |  12 |  14 |  218 |  0    
    Field:  ADDR4                            |  30 |  13 |  14 |  248 |  0    
    Field:  ZIPCOD                           |  10 |  13 |  59 |  278 |  0    
    Field:  NETWORK                          |  62 |  15 |  19 |  288 |  0    
    Field:  LAST_UPDATE                      |  23 |  18 |  15 |  350 |  0    
    Field:  MULTI_NODE                       |   1 |  18 |  52 |  373 |  0    
    Field:  DELETED                          |   1 |  18 |  67 |  374 |  0    


The SMNETUPDT program uses the following structure for records read from a
remote NETWORK.DAT file:

USER:       Length 30,                   position  0
NODE:       Length  6,                   position 30
TIMESTAMP:  Length 16,                   position 36
MIDDLE:     Length (record length - 54), position 52
MULTI_NODE: Length  1,                   position (record length - 2)
DELETED:    Length 1,                    position (record length - 1)

The record length is found at run-time, from each record that is read.  The same
structure is used to write records to the local NETWORK.DAT file.  So it doesn't
matter what fields or data you have in the 'MIDDLE', or what length they are,
as long as the two NETWORK.DAT files have the same record length and format.

If the two files have different record lengths, SMNETUPDT will refuse to update
existing records, but will create new records *with the length of the remote
record*.  So if the local records are shorter, data is lost off the end; if
local records are longer, the MULTI_NODE and DELETED fields don't end up at the
end of the record.

So to summarise: SMNETUPDT will work with customised NETWORK files, provided
that:

1. The USER, NODE and TIMESTAMP fields are not changed in length, or position,
   within the record
2. The MULTI_NODE and DELETED fields are not changed in length, or position,
   within the record.
3. All NETWORK files being accessed by SMNETUPDT have the same record layout.

Scott

Hi,

I've just re-read .10, and had another look at this.  It appears that prior
to 1986, SMNETUPDT (erroneously) used the LAST_UPDATE field instead of the
TIMESTAMP field.

The symptoms in .10 suggest that the customer may still be using an old version
of SMNETUPDT.  Please can you do $ ANALYZE/IMAGE OA$LIB:SMNETUPDT.EXE and see
what version is given in the image ID?  It should be V2.3 (the image ID didn't
change in V2.4 as the program didn't change).

Scott

    ANALYZE/IMAGE of SMNETUPDT.EXE shows a version of ALL-IN-1 V2.4.
    
    The record layout that you posted has a different ordering than the
    customer's NETWORK.DAT.  I modified the NETWORK form .FLG file to
    reflect the new ordering, used OA$CNV_CONVERT to convert to the "real"
    order, and retested UA.  SMNETUPDT worked like a charm.
    
    Thanks for the support.  There was a light at the end of the tunnel,
    and this time it wasn't an oncoming train...
    
    David

    I have developed a kit for customizing ALL-IN-1 V2.4 to expand the
    network address field in NETWORK.DAT from 62 to 126 characters.  This
    customization enables NETWORK.DAT to store X.400 addresses.
    
    The customization was performed on 6 ALL-IN-1 VAXclusters at Kellogg
    Company and has been in production for several months.
    
    The kit includes step by step instructions, and all required .FDL and
    .FLG files.
    
    If anyone is interested in the kit, please contact me at DTN 456-1765
    or VMSmail at GLDOA::FINKELSTEIN.
    
    
    David