Help processing .toc files created by inutoc
Jason Wells
to process the info from these files because the filesets are on CD and
gziped... I am hoping to find a better way to do this than grepping or
parsing with Perl...
Any ideas?
Thanks.
Niel Lambrechts
I hope i understood you right.
Copy the files from CD to a directory and uncompress them so they have a
.bff extension.
Then run "inutoc ." in this directory and a new .toc file will be created.
smitty install_all will then use the .toc to allow installation of filesets.
Niel
Jason Wells
What I was hoping to find, is that there is some command that can list the
contents of a .toc file so that I don't have to write code to parse it. I
am worried that the format may have some surprises that my code won't
anticipate.
I can't really unzip the files and expect to have enough local space to copy
them to.
steven_nospam at Yahoo! Canada
> What I was hoping to find, is that there is some command that can list the
> contents of a .toc file so that I don't have to write code to parse it. I
> am worried that the format may have some surprises that my code won't
> anticipate.
>
> I can't really unzip the files and expect to have enough local space to copy
> them to.
Jason,
Why would you want to re-invent the wheel? The .toc file is a table of
contents of what is on your CDROM or (if you use inutoc like Niel
proposed) it is a table of contents of the bff files in the selected
directory.
IBM gave us tools to use the smit install command that reads the .toc
and lets you install what you need. The .toc I would guess (at least
from looking at them) are in a proprietary format and I am not sure you
will find a way to interpret them for your own scripts.
If you just want to see what files the table of contents is expecting
to find, you can issue this command:
grep bff .toc|awk '{print $1}'
I don't know if that helps at all. Perhaps you can explain why you are
trying to parse the .toc file instead of just letting smitty do the
work...
Jason Wells
> Jason,
>
> Why would you want to re-invent the wheel? The .toc file is a table of
> contents of what is on your CDROM or (if you use inutoc like Niel
> proposed) it is a table of contents of the bff files in the selected
> directory.
>
> IBM gave us tools to use the smit install command that reads the .toc
> and lets you install what you need. The .toc I would guess (at least
> from looking at them) are in a proprietary format and I am not sure you
> will find a way to interpret them for your own scripts.
>
> If you just want to see what files the table of contents is expecting
> to find, you can issue this command:
>
> grep bff .toc|awk '{print $1}'
>
> I don't know if that helps at all. Perhaps you can explain why you are
> trying to parse the .toc file instead of just letting smitty do the
> work...
I need a script to load certain filesets depending on the machine's
configuration(and depending on the versions of the filesets)... It looks
like parsing the .toc file may be the only option. I was just hoping there
was a command that would do it.
Thanks for the replies,
Jason
steven_nospam at Yahoo! Canada
Jason Wells wrote:
> I need a script to load certain filesets depending on the machine's
> configuration(and depending on the versions of the filesets)... It looks
> like parsing the .toc file may be the only option. I was just hoping there
> was a command that would do it.
>
> Thanks for the replies,
> Jason
IBM's smit install menu has this feature:
- Update Installed Software to Latest Level (Update All)
That would pick only the software and pre-reqs that were already
installed on your system and update them. Assuming that you did the
install once and got the filesets you wanted, then this should just
update the ones you need from that point on.
Would this help or are you trying to write the script for initial
installations? If so, how do you decide if a particular fileset is
required, a dependent, co-dependent, or not required on a particular
system?
We kind of do the same thing as what you are saying...We used to have
AIX 3.2.5 installed on a 1GB disk, 4.2.1 on a 2.2GB, and 4.3.3 on a
4.5GB after stripping it down to bare bones. If we installed ALL
filesets, we probably would have software on the system for things that
we don't even use (for example SSA RAID configs when we only have SCSI
disks and no RAID setup or certain ethernet or graphic card filesets).
However, we do not try to tailor it too much, when in doubt, install it
or let the O/S check the system and decide if it needs it.
Good luck with the project ;-)
Jason Wells
> IBM's smit install menu has this feature:
>
> - Update Installed Software to Latest Level (Update All)
>
> That would pick only the software and pre-reqs that were already
> installed on your system and update them. Assuming that you did the
> install once and got the filesets you wanted, then this should just
> update the ones you need from that point on.
>
> Would this help or are you trying to write the script for initial
> installations? If so, how do you decide if a particular fileset is
> required, a dependent, co-dependent, or not required on a particular
> system?
>
> We kind of do the same thing as what you are saying...We used to have
> AIX 3.2.5 installed on a 1GB disk, 4.2.1 on a 2.2GB, and 4.3.3 on a
> 4.5GB after stripping it down to bare bones. If we installed ALL
> filesets, we probably would have software on the system for things that
> we don't even use (for example SSA RAID configs when we only have SCSI
> disks and no RAID setup or certain ethernet or graphic card filesets).
>
> However, we do not try to tailor it too much, when in doubt, install it
> or let the O/S check the system and decide if it needs it.
>
> Good luck with the project ;-)
Yeah, it does need to be non-interactive and it is for fresh installs... We
have a way to determine which filesets to load, now I just need to be able
to inspect the gziped filesets without extracting them -> using the .toc
file to determine the versions... It's not to hard to read the .toc, I'm
just worried there may be some unexpected end-cases...
Jason Wells
It looks like 'installp -l -d <path>' does what I need! sweet!