Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace AIX
Created by Guest
Created on Feb 7, 2020

Introduce "generic" full & easily machine parsable output for AIX commands

Command part of "list" category (lsvg, lslv, lssyscfg, lsdev, lsattr, ....) provide the entry point to capture configuration of AIX OS.
Allowing all theses kind of commands to provide "full & easily machine parsable output" using flag (like already do "lsattr -O") will greatly enhance capability to interact with system.
All automated "configuration collection" will be more powerful (shell script, Ansible, ... ) and POWER platform will so be easily deployed, maintained, .... thru automata.

Proposal :
Search for a "not already used" option and reserve it as "generic AIX command standard option" for any new "ls*" command that may be developed later on AIX (same as -v is for version and -h is for help).
Having one generic option that "work everywhere" (ie, avoid one different option per command) will provide more ease of use.
This new option could be "--csv" if easily possible to use "double dash" options within AIX current commands.
Also use "--delim" in order to specify the delimiter to be used (personally I like semi-colon as it is never part of "value" due to its specific shell meaning, but quite sure other people have other preferred delimiter).
Add of the header in first line is mandatory in order to avoid any "foreign data" to be parsed in case of command evolution. A good direction will be to use "#" as first char in order to identify the header line easily and process it as wished. Ie: as part of "one time usage" small shell script, a simple syntax like <my_aix_command --csv | grep -v -e"^#"> will remove the header line (as any comment line within UNIX world). An for more "durable" implementation like Ansible, it will be possible to keep the header line aside and compare the expected header with the one provided by the command, so in case command evolve, there is way to detect new "fields" additions and avoid to integrate "wrong data" because it moved to an other field or was removed because obsolete or wathever reason.
Of course the "formatting output" should combine with existing flags (ie: lsvg does not provide same info than lsvg <vgname> nor lsvg -P <vgname> nor any other used options) as "simply" an "machine readable output formatting".

Going this way (by addition of exhaustive format) will avoid any regression for existing scripts parsing "human readable" aix command output, and will allow aix to move lot more easily to era of automata/Infrastructure As Code/Ansible/...

This will be like a small command change (add of new output format) but giant leap for automation/Infrastructure as a code.

Idea priority High
  • Guest
    Reply
    |
    Mar 16, 2023

    While I agree with the idea itself - many commands could have output more easily parsable than right now - i disagree strongly with the idea to introduce "--<arg>" as a way to do it. The double-dash is a (non-POSIX) GNU extension to getopts and one doesn't need that in a UNIX system. It sure is possible to find unused command options for every command to access such a functionality. Alternatively there could be an enviroment setting like "export OUTPUTFORMAT=MACHINEREADABLE" to trigger a certain format.

  • Guest
    Reply
    |
    Nov 20, 2022
    IBM has evaluated the priority of this enhancement proposal relative to other future product content and determined that this Idea will not be pursued for a future product release
  • Guest
    Reply
    |
    Feb 21, 2020

    An interesting idea, certainly worthy of consideration.

    Please note> one reason the commands have not changed is because these are the layouts that have been available since the late 70's and early 80's. That Linux, e.g., decided to drop many standard commands and replace them with new commands does not break all the programs people have used for years to automatically process these standard ls* commands.

    As to two other points: the option -c is frequently used to output results in a single line (noteably in AIX legacy commands such as lslpp, not is classic POSIX commands) and frequently there is an option to omit headers completely.

    If this can be done, without breaking compatibility to existing commands - great. Otherwise, I would hesitate to see how many things a change such as this would break for people, as myself, who have worked on and used these programs - asis - for over 25 years.

  • Guest
    Reply
    |
    Feb 15, 2020

    I definitely agree, some standardization could be good here, specifically, perhaps adding the -F flag to LVM and VPD queries.


    _______________________________________________
    Device commands do have a standardized way to get this:
    _______________________________________________


    #################
    For lsdev, you can use -F
    #################
    # lsdev -H -Ccadapter -F 'name;class;subclass;type;location;physloc;description'
    name;class;subclass;type;location;physloc;description
    ent0;adapter;pciex;df1020e2e304;02-00;U78D2.001.XXXXXXX-P1-C9-T1;PCIe3 4-Port 10GbE SR Adapter (df1020e21410e304)
    ...


    #################
    For lsattr, you can do the same
    #################
    #lsattr -El sys0 -H -F 'attribute:value:description:user_settable'
    attribute:value:description:user_settable

    SW_dist_intr:false:Enable SW distribution of interrupts:True
    autorestart:true:Automatically REBOOT OS after a crash:True
    boottype:disk:N/A:False
    capacity_inc:0.01:Processor capacity increment:False
    capped:false:Partition is capped:False
    chown_restrict:true:Chown Restriction Mode:True
    clouddev:0:Recreate ODM devices on next boot:True
    conslogin:enable:System Console Login :False
    cpuguard:enable:CPU Guard:True


    _______________________________________________
    However, VPD is less standardized.
    _______________________________________________

    #################
    For lssyscfg, I assume you mean lscfg -vl. That command is brutal to parse, and ODM does not have all of this. You can get useful data with:
    # lsvpd | while read type data ; do if [[ "${type}" == "*YL" ]] ; then echo "" ; fi ; echo "$type $data" ; done | more | grep -p fcs0
    *YL U78D2.001.XXXXXXX-P1-C9-T4
    *FC ????????
    *DS PCIe3 4-Port 16Gb FC Adapter (df1000e314101406)
    *AX fcs0
    *PL 03-00
    *CD 10140614
    *PN 01FT695
    *SN Y050HY95A012
    *EC P14609
    *CC 578E
    *MF 001D
    *FN 01FT699
    *ZM 3
    *Z0 0000000C
    *Z1 00000001
    *Z2 00000000
    *Z3 08090000
    *Z4 01000001
    *Z5 2E343135
    *Z6 2E343135
    *Z7 C0022C40
    *Z8 20000010XXXXXXXX
    *Z9 11.4.415.5
    *ZA 11.4.415.5
    *ZB 00000000
    *ZC 00040000
    *ZD 000000FF

    In this case, it's missing "Network Address", but you can usually convert Z8. This doesn't work on virtual though. I usually do something more like this to get the data I want:

    for fcs in `lsdev -C | grep fcs | cut -f 1 -d \ ` ; do
    fscsi=`lsdev -p$fcs | grep -i scsi | cut -f 1 -d \ ` ; hn=`hostname`;
    echo $hostname `lscfg -vsl $fcs | egrep 'fcs|Address' | tr . \ | tr -s [:space:]` FC ID: `lsattr -a scsi_id -F value -El $fscsi` ; done

    vio2a fcs0 U78AE 001 XXXXXXX-P1-C19-L1-T1 Network Address 10000090FXXXXXXX FC ID: 0x450200
    vio2a fcs1 U78AE 001 XXXXXXX-P1-C19-L1-T2 Network Address 10000090FXXXXXXX FC ID: 0x460200

    That works on virtual hosts also.


    _______________________________________________
    LVM is the worst, and requires transformation
    _______________________________________________
    Other than cutting out specific data that you need, the AIX way is to use mkvgdata, and then parse the image.data file it produces.

    Alternatively, you can do something like this:

    # (lsvg rootvg | cut -c 1-45 ; lsvg rootvg | cut -c 46-999 ) | cut -f 1 -d \( | tr -d \ | tr : \ | while read variable value ; do echo ${variable}=${value} ; done | egrep -v '=$' | sort -r
    VOLUMEGROUP=rootvg
    VGSTATE=active
    VGPERMISSION=read/write
    VGIDENTIFIER=00XXXXX00000YYYYY0000ZZZZZZZZZZZ
    ...

    This same works with lslv, or often you can get key info from "lsvg -l rootvg" or similar.

  • Guest
    Reply
    |
    Feb 10, 2020

    An additional improvement would be to have JSON output (say '--json'), as this would facilitate direct ingestion into multiple platforms.